In the previous blog article, we discussed the capabilities of Lync 2013 LBR that was introduced in CU1. This allows the prevention of PSTN Toll By-pass which is prohibited by government regulations in countries such as India. For example, Lync user A in Delhi can make a call to a local Delhi PSTN number using the PSTN Gateway in Delhi. But when the same user travels to Mumbai and tries to make a call back to a local Delhi PSTN number, LBR will not allow this user to use the same PSTN Gateway in Delhi via the Mumbai-Delhi WAN link. While this covers the Peer-2-Peer calling restrictions, it does not address conferencing scenarios. For example, Lync user A in Delhi first makes a call to a local Delhi PSTN number using the PSTN Gateway in Delhi, then adds Lync user B in Mumbai to create a 3 party AVMCU conference. If the conference is allowed, then User B is effectively using PSTN Toll-Bypass, and TRAI regulations also prohibit the mixing of VOIP and PSTN calls. To address this scenario, we need to configure and enable Conferencing LBR, which was introduced in Lync 2013 CU2. In this article we explore the configuration of Conferencing LBR and testing with Polycom CX600 phones. Below is the diagram of the test scenario:
5 Comments
In this lab, we use a standard edition Lync server configured with an Asterisk PBX to simulate a PSTN connection. The diagram of this setup is shown below:
Below is the overview of the steps involved:
1. Configure Networking 2. Load SSL Certificates 3. Add Virtual Service
The starting point for this article is an already fully functional Lync2013 on-premise deployment complete with Edge server deployed with federation enabled and all modalities working properly. All the necessary external and internal DNS records are already in-place and public SSL certificates are already assigned to the Lync Edge services and Reverse Proxy services. At the same time, an enterprise Office365 tenant to build the split domain topology on must also be available. In this setup an O365 E3 tenant is used for the hybrid deployment. Readers who do not have a tenant can sign up for a 30-day E3 trial here. Note also that the desired shared SIP address space must be a publicly verifiable domain therefore domain suffixes such as ".local" will not work. Ownership of the SIP domain is also required along with the ability to create public DNS records and purchasing of public SSL certificates. With all these in place, a quick overview of the steps involved is summarized below:
As we continue to see increasing numbers of Enterprises and SMBs choose Microsoft Lync 2013 as their preferred UC Platform, the Lync Enterprise Voice workload continues to gain tremendous momentum as companies seek to replace their legacy PBX with Lync. Whilst some companies may choose to deploy headsets for selected departments such as the Contact Centre, today we find that most users still prefer to use Desktop Phones for their everyday voice communication. This is simply because headsets require that the users’ PC/Laptop must always be on, online and logged into Lync, in order to make or receive calls. Our modern workforce today demands not just being always connected, but being always connected instantly. In contrast to Headsets, a Desk Phone requires no PC/Laptop, is always on, always connected, consumes much less power than a PC; and more importantly, allows instant communication by simply picking up the receiver to answer call when the phone rings; or just pressing one button to make that important call to a client. Choosing the right IP Desktop Phone to suit different departmental needs and budget is important to ensure a successful Lync Voice deployment, and there are many choices in the market today. This article discusses 5 important factors that must be considered when choosing IP Desk Phones for Lync 2013 Voice. So you've got a brand new Lync Server 2013 setup along with Exchange Server 2013 SP1. Apart from creating users and configuring Lync and Exchange specific features, you also want to integrate the two servers for many better-together features. Most commonly this will include: 1. Leveraging Microsoft Exchange Server 2013 Unified Messaging for Microsoft Lync Server 2013 voicemail 2. Enabling the use of high-resolution photos in Microsoft Lync Server 2013 3. Configuring Microsoft Lync Server 2013 to use the unified contact store 4. Enabling Lync client features in Microsoft Outlook Web App 2013 Following the guidelines in TechNet are definitely useful but some essential steps are missing and since the information scattered around in different locations, this article provides 3 easy steps to get the pre-requisites configured correctly to prepare for configuring better-together features. With the introduction of Windows Fabric in Lync 2013, user services data is now written to 3 RTCLOCAL\RTC replicas in the FE Pool, known as the primary, secondary and tertiary replicas. This data is then lazily written to the backend SQL Database for rehydration and FE Pool startup purposes, thereby allowing greater scalability of the FE Pool. For more information on how Windows Fabric works in Lync 2013, I would recommend reading this blog article from MCM Richard Brynteson. Querying the RTCLOCAL database can be useful for troubleshooting purposes. Unfortunately, the default install of SQL2012 Express on each Lync FE Server does not include SQL management studio 2012 for querying the RTCLOCAL databases. This brief post walks through what needs to be installed on the LyncFE Server to get SSMS 2012 running. First we need to grab the SQL 2012 Express install bits from http://www.microsoft.com/en-us/download/details.aspx?id=29062. Start the installation and on the first screen, select the first option as shown below:
Polycom’s VVX family of VoIP handsets are ideally suited for customers deploying Lync 2013 Enterprise Voice to replace their legacy PBX systems. Unlike the Lync Phone Edition (LPE)handsets which run Microsoft WinCE, the VVX has it's own software running known as UCS, the latest being version 5.0.1 and newer versions are continuously being developed with enhanced feature sets based on customer demand. UCS allows for a great deal of flexibility in its configuration compared with its LPE counterparts. In fact there are thousands of parameters that can be configured but there are a limited set of these which are relevant in a Lync voice deployment which is described in this official document from Polycom. To configure these parameters a provisioning server must be setup for the phone to download the parameters from predefined configuration files. A provisioning server is simply a FTP or HTTP server. Readers unfamiliar with setting up and using a provisioning server should refer to the same document mentioned. This article covers 5 useful configuration parameters for a Lync Enterprise Voice deployment. The Polycom RealPresence Group Series are the latest family of Room Telepresence systems suited for high-quality video collaboration in meeting room and board room environments. With support for 1080p60 coupled with all new EagleEye-IV camera with up to 12x optical zoom and a 4K CMOS sensor, the Group Series family brings video to a new level of realism especially in meeting rooms equipped with large displays. Up until recently, the Group Series along with its predecessor the HDX family, only supported Microsoft RTV video codec that allowed for up to only 720p30 video. With the latest 4.1.3 firmware for Group Series released on 24 Feb, there is now support for Microsoft's native SVC implementation known as X-H264UC. What this means is that not only peer-2-peer calls between Lync 2013 clients and Group Series endpoints can reach up to 1080p30 HD resolution, the Group Series now can receive up to 5 simultaneous video streams from the Lync AVMCU, providing a conferencing experience similar to Lync's own Gallery View where up to 5 active speakers can be seen simultaneously. Unlike the Lync client, the 5 video streams are not displayed in a horizontal row on the Group Series' display. Rather, the 5 streams layout makes full use of the display's real estate to maximize the video window for each participant. The diagrams below show the display from both a Lync client (left) and a Group Series 500 (right) with each having 5 video participants displayed: Microsoft's Lync Room System (LRS) is the latest addition to the family of client editions built for Lync Server 2013. LRS is optimized to bring the immersive Lync meeting experience to participants in a meeting room. With its slick surface-like user interface, LRS makes joining meetings a "one-finger-touch" experience. During the meeting, LRS brings together both in-room and remote attendees, allowing everyone to see and collaborate on content as well as view each other in full high definition video. Microsoft provides the LRS software to certified OEM partners which include Crestron, Polycom and Smart. This article explores the various topologies which are supported by LRS and walks through provisioning an Office365 environment for LRS. Full details of deploying an LRS for both on-premise and online environments can be downloaded here. Supported Topologies
LRS supports on-premise Lync environments, pure Office365-S environments, as well as hybrid Lync On-Premise + Exchange On-Line environments. What's not supported today are Hybrid topologies with Lync On-Line with Exchange On-Prem. As of this writing, Microsoft is also testing LRS with Lync Hosting Pack and Office365-D; supportability statements for these can be expected in the coming months. The table below summarizes the various supported topologies today: In Part 1 of this article we walked through the steps to deploy a Lync 2013 SBA in a simulated branch office environment. Here in Part II, we will perform some tests of the SBA to verify the correct functional behavior using Microsoft-certified IP deskphones such as the Polycom CX600 LPE and the Polycom VVX310/410 Business Media phones. We also collect some performance results of the failover and failback times in this lab. The diagram for this lab environment consists of a Lync 2013 SE FE server in the "Main Site" and an Audiocodes M800 SBA in the "Branch Site". In the main site we have a Lync 2013 PC Client and a Polycom VVX410 phone and both accounts used to login are homed on the Lync SE FE server. At the branch site we have a Polycom CX600 phone and a Polycom VVX310 phone and both account used to login are homed on the SBA. Below is the diagram of this setup: The following tests will be performed in the sequence below:
Test #1: WAN Link Up: 1a. Login to all phones using PIN Auth 1b. Login to all phones using NTLM Auth 1c. P2P voice calls between Main site and Branch Site 1d. Multiparty voice calls between Main site and Branch Site Test #2: WAN Link Down 2a. Phone registration status after WAN Link is down and failover time 2b. Initiate P2P calls within Branch site 2c. Phone registration status after WAN Link is restored and failback time Test #3: WAN Link Down during active calls 3a. Initiate P2P voice call within Branch site, then WAN Link fails 3b. Initiate multiparty voice call between Main site and Branch site, then WAN Link fails Just to recap, the SBA is an appliance preinstalled with Lync Registrar, Mediation Server and PSTN gateway that provides survivable telephony services to branch users in the event of a WAN outage between the branch and the main data centre hosting the Lync servers. Part 1 of this article provides a walk-thru of the steps for deploying and SBA in a Lync 2013 environment. Part 2 will focus on gathering some test results of SBA failover/failback times as well as telephony performance when used with and without Response Groups. The SBA used for this lab test is the Audiocodes Mediant800 SBA and the phones used are a Polycom CX600 Lync Phone Edition and Polycom VVX600 Lync-Compatible phone handsets. Steps to deploy an SBA are well documented in both TechNet as well as in Audiocodes' installation manual and therefore will not be repeated in detail here. The main focus of this article would be the highlights of this specific lab deployment as well as the test results of the telephony performance. The SE Lync FE server role is virtualized with Hyper-V with 4 Virtual CPU's and 4GB memory. Upgrading Audiocodes SBA to Lync 2013 The Mediant800 used for this article was originally built for a Lync 2010 SBA and thus has to be upgraded to Lync 2013 for this deployment. The upgrade method used in this lab was the USB Upgrade and Recovery procedure. This is a straightforward process and the default settings on the RecoveryUtil.ini file on the USB stick can be used. Obtain the new Lync2013-based .wim image file from Audiocodes and copy it to the USB stick. Then plug the USB stick to the USB port at the back of the Mediant800 and power up. The system should boot from the USB and start the imaging process automatically. Once imaging is complete remove the USB and allow the system to reboot. Configuring AD and Lync Server for SBA deployment The SBA must first be added into AD as a computer object using the AD Users and Computers tool. In this lab our computer object settings are as shown on the right. The Default Admins group is chosen as per default since we are working with the Domain Admin account. Next the computer object must be added as a member of the RTCUniversalReadOnlyAdmins group. Next, we use ADSIEdit to edit the properties of the computer object and set the attribute servicePrincipalName to "HOST/<SBA FQDN> as shown below. Finally we create a new user account belonging to the RTCUniversalSBATechnicians group for performing the Survivable Branch Appliance deployment. In my lab setup I have Exchange 2013 CU1 server with Mailbox and CAS role installed. Exchange UM is enabled and integrated with Lync Server 2013 CU1. As Exchange 2013 does not have an Edge Transport role, the lab environment uses Exchange 2010 as the Edge Transport server. Below is the simplified diagram of the setup (firewalls and reverse proxy omitted). Everything was working fine until Lync Phone Edition (LPE) devices and VVX Lync-compatible phones were no longer able to access the Exchange Voicemail subscriber access and auto-attendant like they used to. A quick test using the Lync client also had issues accessing the Voicemail and a snooper trace showed multiple following MS-Diagnostic errors:
"ms-diagnostics: 15007;reason="Exchange Unified Messaging server did not respond to request" "ms-diagnostics: 1038;reason="Failed to connect to a peer" "ms-diagnostics: 15030;reason="Failed to route to Exchange Server" However, Exchange calendar integration continues to work on the LPE and VVX phones. This suggested that UM integration was failing because of an recent attempt to update the Exchange 2013 server to CU2. That update failed during prerequisite checks with an error message saying that there were one or more Exchange 2010 servers in the organization that has not yet been updated to SP3. However the Exchange 2010 Edge transport server was already running SP3 so it was unclear why this message appeared. To resolve this issue, I performed the following steps: 1. Remove the Edge Subscription on the Exchange 2013 server using the cmdlet Remove-EdgeSubscription - identity <edgeservername> Publishing Exchange 2013 Web Services (EWS) to clients on the external network is essential for Lync 2013 Unified Contact Store (UCS) and Lync 2013 Mobile clients to work properly. Without EWS available to clients on external networks, Lync 2013 Mobile clients will be unable to get Lync contacts when UCS has been enabled for users, since these contacts are now stored in Exchange. Lync 2013 Mobile clients will also not be able to retrieve calendaring information to join Lync online meetings. In order to enable these functions for the full Lync mobile experience, EWS must be published. This article provides configuration details for publishing Exchange 2013 EWS using Forefront TMG2010. Note that TMG2010 is no longer available for purchase but Forefront Unified Access Gateway (UAG) with Service Pack 3 (SP3) is still available and can be used for publishing Exchange 2013. To begin use the "Publish Exchange Web Client Access" in the TMG 2010 Task pane to start the wizard. Give the rule a name and in the Select Services screen choose "Exchange Server 2010" and click on "Outlook Anywhere". Next we can either choose to publish a single Exchange CAS server, which is the case in this lab, or if an array of CAS servers are deployed then the publishing type should be set to a server farm. Then we select to use SSL for the connection from TMG to CAS:
Polycom's broad range of voice and room telepresence solutions for Microsoft Lync has been updated over the past several months for compatibility with Lync 2013 server and clients. This article provides a brief summary of the updates released by Polycom at the time of this writing. It does not cover the detailed specifics of integrating Polycom's solutions with Lync and readers looking for guidance on this should refer to official documentation from Polycom or contact their local Polycom representatives. Voice Solutions Polycom's range of voice solutions are now supported with Lync 2013 and these include the CX Family, SoundPointIP Family and VVX Business Media Family of desktop and conference phones. Details of these solutions can be found on the Polycom website. Microsoft's TechNet maintains the list of voice solutions that are certified to work with Lync 2013 / 2010 here and an excerpt from this page is shown below: RoomTelepresence Solutions The Polycom HDX family and Group Series family of RealPresence Room solutions have also been updated for Lync 2013 support. The specific firmware revisions required are 3.1.2 for HDX and 4.1.1 for Group Series. Existing Polycom customers may download the latest firmware revisions at the support website here. To quickly depict the ease of configuration of Polycom's solutions to work with Lync 2013, below is a screen capture from the Group Series web UI that shows the parameters required: For full details on how to integrate Polycom solutions with Microsoft Lync environments, please refer to the Polycom® Unified Communications Deployment Guide for Microsoft® Environments available here. Lync 2013 Mobile Client
All of the above firmware versions work with Lync 2013 using the legacy RTV codec and have been tested with the full PC versions of Lync 2013. Although the Lync 2013 mobile client does provide support for RTV as well, there's currently no official support from Polycom for Lync 2013 mobile clients. This article walks through the process of buying and setting up GoDaddy's SSL certificates for use on either your Lync Edge server or your Reverse Proxy. In this article, I am using a SSL cert for my Exchange virtual directories that will be published using the reverse proxy Forefront TMG 2010. This is also the same reverse proxy being used to publish the Lync web services. Although there are many types of SSL certs available, for Lync or Exchange environments, the "Multiple Domains UCC" SSL cert from GoDaddy can be purchaesd and used as shown below: Once purchased, you can login to the account and launch the SSL certificate setup as shown below:
In a recent Lync 2013 implementation, I was facing an issue with A/V not working between internal and remote Lync clients trying to establish a video call. The call gets initially connected but then drops after a few seconds with a error message on the Lync client showing "Call failed due to network issues". Both users are homed on the same FE server and therefore use the same A/V Edge server for remote and federated connectivity. A snooper trace on the call flow shows the following error in the "BYE" message: ms-client-diagnostics: 23; reason="Call failed to establish due to a media connectivity failure when one endpoint is internal and the other is remote";CalleeMediaDebug="audio:ICEWarn=0x80012b Google search results on the error message shows several websites which recommend that the solution was adding an A record in the internal DNS for the External AV Edge FQDN pointing to the external NAT'ed public IP address so that internal Lync clients can contact the AV edge. This is not mentioned in any of the official MS guides and I can confirm this recommendation to be incorrect and doing so did not resolve the issue for me. There is no requirement for this record to be created in the internal DNS in order for remote or federated A/V calls to work. To troubleshoot the issue, I looked at the "183 Session Progress" message which I've reproduced below:
a=candidate:1 1 UDP 2130706431 172.21.5.64 26698 typ host a=candidate:1 2 UDP 2130705918 172.21.5.64 26699 typ host a=candidate:2 1 UDP 2130705919 10.230.78.13 22972 typ host a=candidate:2 2 UDP 2130705406 10.230.78.13 22973 typ host a=candidate:3 1 TCP-PASS 174455807 140.242.214.33 52910 typ relay raddr 172.21.5.64 rport 29837 a=candidate:3 2 TCP-PASS 174455294 140.242.214.33 52910 typ relay raddr 172.21.5.64 rport 29837 a=candidate:4 1 UDP 184547839 140.242.214.33 57234 typ relay raddr 172.21.5.64 rport 18984 a=candidate:4 2 UDP 184547326 140.242.214.33 55494 typ relay raddr 172.21.5.64 rport 18985 a=candidate:5 1 TCP-ACT 174847999 140.242.214.33 52910 typ relay raddr 172.21.5.64 rport 29837 a=candidate:5 2 TCP-ACT 174847486 140.242.214.33 52910 typ relay raddr 172.21.5.64 rport 29837 a=candidate:6 1 TCP-ACT 1684796927 172.21.5.64 29837 typ srflx raddr 172.21.5.64 rport 29837 a=candidate:6 2 TCP-ACT 1684796414 172.21.5.64 29837 typ srflx raddr 172.21.5.64 rport 29837 From the excerpt above, we can see that the ICE negotiation had started and IP-Port candidates are being send to the other Lync client. The Lync client on the other end of the call also sends it's candidates list in a 182 Session Progress message thereafter which the two Lync clients will attempt connectivity checks to determine which of the candidates can be used. After connectivity checks have passed then the call should proceed with a 200OK message containing the selected working candidates but in the SIP trace, there is no such 200OK message. Instead the call is dropped with a BYE message containing the error message above. This means that connectivity checks have failed for some reason which could be the result of firewall ports being blocked. A check with the firewall admin revealed that port 3478 UDP was not open bi-directionaly on the AV Edge external interface. This would certainly impact AV Edge connectivity. True enough, after opening UDP 3478 Bi-Directional on the AV Edge external interface, calls started working normally. SIP trace shows the following 200OK message after the 183 Session Progress: a=candidate:5 1 UDP 1862270207 10.222.209.53 50105 typ prflx raddr 192.168.2.100 rport 28440 a=candidate:5 2 UDP 1862269950 10.222.209.53 59886 typ prflx raddr 192.168.2.100 rport 28441 Instead of a just a server reflexive address (srflx) presented in an INVITE or 182 Session Progress message, we now see a peer reflexive address (prflx) in a 200OK message which points to the AV Edge pre-NAT IP address. One additional point to note is that the port range UDP 50,000-59,999 is NOT required to be open on the AV Edge external interface, unless federating with OCS2007. Both OCS2007R2 and Lync 2010/2013 do not require this port range to be open since these versions support the use of tunneling media ports through 3478 or 443. To understand more, I would recommend watching the TechEd2012 Lync Deep Dive session on ICE available at http://channel9.msdn.com/Events/TechEd/Europe/2012/EXL412 A good place to start understanding how the Mobility Service works is here: http://technet.microsoft.com/en-us/library/hh690030.aspx. Most of the steps are already provided in Technet but I find that many of the key essential must-do's are scattered in various pages rather than being consolidated in a single location. Hence, this article serves as a companion to the Technet documentation and is intended for anyone who is encountering difficulty in successfully getting the Mobility service to work. It will also be useful in case I ever need to deploy the Mobility Service again in a different environment and do not wish to spend time to troubleshoot the commonly encountered issues. The diagram below reproduced from Technet is very helpful to understand the how the mobility service works: Tip#1: Lync Internal and External AutoDiscover DNS recordsDuring Automatic Discovery, mobile devices will first use DNS lookup to the internal DNS record lyncdiscoverinternal.<internal domain>. If not found, it means that the client is on an external network and will then lookup the external DNS record lyncdiscover.<sipdomain>. A mobile device that is internal to the network connects to the internal Autodiscover Service URL, and a mobile device that is external to the network connects to the external Autodiscover Service URL. For split-brain DNS environment, the internal autodiscover DNS record should exist in the internal DNS and not in the external public DNS. Vice versa, the external autodiscover DNS record should exist in the external public DNS and not in the internal DNS.
With the release of Exchange 2013 CU1, we can finally deploy the Unified Contact Store (UCS) into an existing Exchange2010 SP3 environment. This is because Exchange2013 is required for UCS and the GTM version of Exchange2013 did not support coexistence with previous versions of Exchange. To recap, UCS enables users to store all contact information in Exchange 2013 so that the information is available globally across Lync, Exchange, Outlook, and Outlook Web Access. Without UCS, Lync2013 clients cannot change or upload their photos. Below is the UCS architecture diagram for reference: Deploying Exchange2013 CU1 itself is beyond the scope of this article and the steps are provided in Technet. For existing Exchange2010 environments as in the case of this lab setup, upgrading to Exchange2010 SP3 is required which also performs the prepare AD schema, thereby eliminating the need to run setup.exe /PrepareSchema using Exchange2013. After deploying Exchange2013 we also need to run the post-install steps as described in here. Most notably would be the need to assign a CA issued certificate for the CAS role as Exchange2013, like it's predecessors, by default uses a self-signed cert which Lync2013 will not recognize. Once the prerequisites are done, enabling unified contact store in Lync Server 2013 does not require any topology settings. All that's needed is that the Unified contact store policy is enabled (default is enabled), user's mailboxes have been migrated to Exchange2013, and user log in with using the Lync 2013 rich client at least once.
The Polycom CX600 is a Lync Phone Edition (LPE) device that is optimzed for Lync2010 and Lync2013 environments. As briefly mentioned in the KB Article for the January2013 CU for LPE devices, this new firmware update actually allows the phones to support Lync Online and Office365. This article descibes how to configure the CX600 for use in Office365 Plan E4 in a lab environment. For Lync On-Premise scenarios, fellow MVP Jeff Schertz has written excellent blogs on how to configure these phones for Lync available here. Since the phones require users to be enabled for Enterprise Voice, only Office365 Plan E4 or Lync Online Plan 3 can be used with the Lync Phones as only these plans include the Enterprise Voice" feature equivalent in Lync On-Premise, which is refered to as "Lync-to-Phone" in Lync Online. In US and Canada, the "Lync-to-Phone" PSTN connectivity is provided by service provider JahJah and this service is not currently available anywhere else in the world. For Office365 users outside US and Canada, PSTN connectivity can still be achieved by deploying an On-Premise Lync environment with PSTN connection via a qualified gateway while still using Lync and Exchange Online in the cloud. These are refered to as Hybrid Lync Server deployments. Details on how to configure phones for these hybrid scenarios will be covered in a future article. In this article we will not configure any PSTN connectivity.
Getting Started: Configuring Exchange Online for UMTo allow the CX600 phones to retrieve VoiceMail and Call Logs, the Exchange Online service must be configured for Unified Messaging UM). To get started, navigate to the Exchange Admin Center and select Unified Messaging on the left tab. Then Click on the "+" button to add a new UM Dial Plan as shown below: On the new UM Dial Plan window, we enter a desriptive name for the dial plan followed by the Extension length which would be the number of digits in the full E.164 number excluding the "+". For eg if the country code is 65 followed by another 8 digits, then extension length would be 10 digits. Next select the "SIP URI" Dial plan type and select the desired audio language. Sample screen shot is shown below:
|
Important LinksMicrosoft Teams Docs Archives
March 2023
Categories
All
This website uses marketing and tracking technologies. Opting out of this will opt you out of all cookies, except for those needed to run the website. Note that some products may not work as well without tracking cookies. Opt Out of Cookies |