UCPrimer
  • Tech Blog
  • About UCPrimer.com

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

6/27/2013

2 Comments

 
Picture
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

Read More
2 Comments

Migrating to Lync2013 Edge Server 

3/13/2013

9 Comments

 
In a previous article, we discussed the steps to deploy a new Lync2013 Edge server into a Lync2013 FE pool that was coexisting with a legacy Lync2010 Pool with Lync2010 Edge. Users homed on the Lync2013 FE pool continued to use the legacy Edge server for remote access and federation. Although having both the legacy Edge and the 2013 Edge providing remote access is possible, such a configuration would be more difficult to manage and moreover, only one Edge can be used for federation. In this article, the steps to migrate completely to the new 2013 Edge will be discussed. Users still homed on the legacy Lync2010 FE pool as well as those homed on the new Lync2013 FE pool  will use the new 2013 Edge for Remote Access and Federation. The end result should look like the diagram below:
Picture
In a production environment, changing the federation route and media traffic route requires downtime for the Lync Server 2013 and Lync Server 2010 Edge Servers. Federated access will be unavailable for the duration of the outage.

Configure the Lync2013 FE Pool to use the new 2013 Edge

In topology builder, edit the properties of the Lync2013 FE and associate the Edge pool with the new 2013 Edge:

Read More
9 Comments

Deploying Lync2013 Edge in Coexistence

2/27/2013

0 Comments

 
Picture
In a previous article, the steps to introduce a Lync2013 Standard Edition FE server into an existing Lync2010 environment was discussed. That existing Lync2010 environment also had an Edge server for remote user access and federation. This article has 2 parts: Part I describes the tasks to connect the Lync2013 FE server to the legacy Lync2010 Edge pool. Part II then describes how to deploy a Lync2013 Edge server in parallel with the legacy edge.
A separate article will be posted later to discuss how to completely migrate all users to the Lync2013 Pool and decommission the legacy Lync2010 components.

Part I: Connecting the Lync2013 FE Server to the legacy Lync2010 Edge Pool

In order to use the federated route that is being used by Lync2010, Lync2013 must be configured to use this route. This is a simple 2-step process. In the Lync2013 Topology Builder, right click the Site and select "Edit Properties..". In the Edit Properties window, click on the "Federation route" in the left pane. Then select the "Enable SIP federation" checkbox and choose the legacy Lync2010 Edge server from the drop down as show below:
Picture
Next, right click the Lync2013 FE node and select "Edit Properties". In the "Edit Properties" select the "Associate Edge pool (for media components)" check box and choose the legacy Edge from the drop down list as shown below:
Picture
Finally publish the topology and wait several minutes for the topology to be replicated across all servers. Then verify that users homed on the Lync2013 FE can federate with external users via the legacy Edge. At this stage, all remote access and federation capabilities are routed via the legacy Edge (Director shown for illustration only) as shown in the diagram below:
Picture

Part II: Deploying Lync2013 Edge

To deploy the Lync2013 Edge in parallel with the legacy environment, there are 5 steps to be performed:
Step 1: Define the new Edge pool in Topology Builder
Step 2: Install Prerequisite software for Lync2013 Edge
Step 3: Deploy the Edge server components
Step 4: Request and Assign Certificates for Edge
Step 5: Start Edge Services

1. Define the new Edge pool in Topology Builder

First, create a DNS A record for the Edge internal NIC. In this lab we use edge2013.apbeta.local as the FQDN of the internal NIC and an IP of 10.222.202.94. The 3 external FQDNs for Access, Web Conferencing and AV are access13.apbeta.local, webconf13.apbeta.local and av13.apbeta.local respectively with IP in the ranges 10.250.27.[146-148]/25. We need to input these parameters when preparing the Edge server in the next step. In the Lync2013 Topology Builder, expand the "Lync Server 2013" node and right click on the "Edge Pool"
node. Select "New Edge Pool..." to start defining the  edge pool properties:
Picture
In the "Define New Edge Pool"  window, click "Next". Since we are installing a single Edge server for this lab, select "Single Computer Pool" and enter the internal FQDN of the Edge server then click "Next":
Picture
In the "Select Features" window, do not enable Federation or XMPP federation. Federation and XMPP federation are both currently routed through the legacy Lync Server 2010 Edge Server. These features will be configured in a later phase of migration. For now, just click "Next":
Picture
Next, select the appropriate IP options and enter the 3 FQDNs of the external interface as defined earlier:
Picture
Picture
Next, enter the Edge internal IP address and click "Next" followed by the external IP address and click "Next":
Picture
Picture
Specify the next hop server to be the legacy Lync2010 FE at this stage. Migration to the new Lync2013 pool will be done later:
Picture
No association of a pool with this Edge pool is selected at this time. External media traffic will continue to route through the legacy Lync2010 Edge. This setting will be configured in a later phase of migration:
Picture
Publish the topology and verify successful completion:
Picture

2. Install Prerequisite software for Lync2013 Edge

Here we prepare a Hyper-V VM with 2 NIC cards and install Windows Server 2008R2 SP1 Standard Edition Full install. We then configure one NIC card for the Edge internal interface and assign the IP 10.222.202.94/24. We also configure the Primary DNS Suffix of this computer to apbeta.local and do not set a default gateway, leaving the adapter DNS settings empty. Lastly, we create persistent
static routes on the internal interface to all internal networks where Lync clients or servers running Lync Server 2013 reside and edit the HOST file to contain a record for the next hop Lync2013 FE server which was configured as the Edge Server next hop address in Topology Builder.

The other NIC card is for the external interface and we configure 3 IP address 10.250.27.[146-148]/26. The internal and external subnets must not be routable to each other. We also configure the default gateway on the external interface and would normally point to an
external DNS. Since we do not have a DNS server in the DMZ in our lab so we will use host files (shown later).

On the Windows2008R2 SP1 server, do the following in sequence:

1. Run Windows Update to get all the latest hotfixes and patches. 
2. Install .NET Framework 4.5 from http://www.microsoft.com/en-us/download/details.aspx?id=30653
3. Enable Windows Powershell Integrated Scripting Envrionment (ISE) from Server Manager->Add Features
4. Install WMF3.0 from http://www.microsoft.com/en-us/download/details.aspx?id=34595 using the correct file. For Windows 2008R2 SP1 it should be Windows6.1-KB2506143-x64.msu
5. Install Windows Identity Foundation from http://go.microsoft.com/fwlink/p/?linkId=204657 using the correct file. For Windows 2008R2 SP1 it should be Windows6.1-KB974405-x64.msu

3: Deploy the Edge server components

Before installing the Edge components, we need to export the topology into a file so we can import into the Edge server. In the Lync2013 Lync Management Shell, run the following cmdlet: "Export-CsConfiguration -FileName c:\config.zip" and copy this file to the Edge server.

Now insert the Lync2013 Server installation DVD into the VM and double-click the icon to autorun the setup. Click Yes when prompted to install Microsoft Visual C++ Redistributable, In the next dialog box, accept the default Installation Location and click "Install". Accept the terms in the license agreement and click "OK" to proceed. In Deployment Wizard click "Install or Update Lync Server System"
Picture
After determining the deployment state, click "Run" in "Step 1. Install Local Configuration Store":
Picture
In the Configure Local Replica of Central Management Store dialog box, choose "Import from a file (Recommended for Edge Servers)" and specify the location of the exported topology configuration config.zip file and then click "Next":
Picture
Click "Finish" when the Local Configuration Store installation is completed. Next click in "Run" in "Step 2 Setup or Remove Lync Server Components".
Picture
In the "Setup Lync Server Components" wizard, click "Next". Then and allow the wizard to complete. There's no input required in this step as the wizard will read the configuration file and install the necessary components. Click Finish to complete the wizard when finished:
Picture

4: Request and Assign Certificates for Edge

First, download the Root CA Chain from the internal CA website, save the chain .p7b file locally and then use the certificates mmc to import the .p7b file into the Edge server's local computer Trusted Root Certification Authorities store:
Picture
Picture
Next, on the Lync Server Deployment Wizard, click on "Run" in "Step 3 Request, Install or Assign Certificates" and in  the Certificate Wizard, select "Edge Internal"  click "Request":
Picture
In the Certificate Request wizard, choose to "Prepare the request now, but send it later..." and in the next screen, enter a local file to save the request and then click "Next", enter a Friendly Name, then the Orgnization info, Geographical info, leave the remaining screens as default until the wizard is completed:
Picture
Picture
Picture
Picture
Picture
Picture
Next navigate to the internal CA website and click on "Request a certificate", followed by "advanced certificate request" and then "Submit a certificate request by  using a base-64-encoded CMC or  PKCS #10 file, or submit a renewal request by  using a base-64-encoded PKCS #7 file.". In the web browser paste the contents of the certificate request file created earlier into the text box and click Submit as shown below:
Picture
Next, download the certificate and save locally to a file:
Picture
Then, back on the Lync Certificate Wizard, click on "Import" to import the downloaded certificate file:
Picture
In the "Import Cerfificate" wizard, select the saved certificate file and click "Finish" to completed the wizard:
Picture
Picture
After importing the certificate, we need to click on "Assign" in the certificate wizard:
Picture
In the Certificate Assignment wizard, we click "Next" and "Finish" to complete the assignment:
Picture
Picture
After getting the internal certificate for the Edge, we now focus on the External Edge. The process is similar and not all the steps will be repeated, but only the differences will be highlighted. On the Certificate Wizard, select "External Edge certificate" and click "Request":
Picture
The remaining steps are similar to those for the internal certificate. Of course a different Certificate Request File should be specified as well as a different Friendly Certificate Name. But the Private Key must be marked as exportable as shown below:
Picture
In the Subject Names windows, note that the two SANs are already added automatically:
Picture
An additional step is required to select the SIP domain to be added to the SAN list:
Picture
In the next step, the lab does not require any additional SANs. Proceeding with the Request Summary page will allow us to generate the CSR which is saved to a file c:\extreq.req
Picture
Picture
Using the same method as the internal certificate, submit the request to the CA and save the certificate. Then import the certificate using the certificate wizard with the "Certificate file contains private key"checkbox cleared:
Picture
Click next to continue and complete the wizard, verifying that the certificate was imported successfully. Back on the certificate wizard, select "External Edge certificate" and click "Assign":
Picture
In the "Certificate Assignment" window click "Next". In the "Certificate Store" window, select the external certfiicate and click "Next":
Picture
In the "Certificate Assignment Summary" window, click "Next". Then verify successful assignment and click "Finish" to end the wizard. Both internal and external certificates should now have a green tick as shown below:
Picture

5. Start Edge Services

Finally, we start the services by clicking "Run" at the "Start Services":
Picture
Verify services are started successfuly and click "Finish" to end the wizard. At this stage, we have introduced a Lync2013 Edge into the mixed environment but are still using the legacy Lync2010 edge for all external access and federation services. In a future article, we will migrate the Remote Access and Media Traffic for Lync2013 users to use the Lync2013 Edge services.
Picture
0 Comments
    Picture
    Picture

    Important Links

    Microsoft Teams Docs
    Microsoft Learn

    ​Microsoft MVP Blogs

    Michael Tressler’s Blog
    Michael’s MTR Quick Tip Videos
    Jimmy Vaughan’s Blog
    Jeff Schertz
    Adam Jacobs
    James Cussen
    ​Damien Margaritis

    Archives

    September 2022
    August 2022
    March 2022
    February 2022
    January 2022
    December 2021
    November 2021
    October 2021
    September 2021
    August 2021
    June 2021
    April 2021
    March 2021
    December 2020
    October 2020
    September 2020
    August 2020
    April 2020
    March 2020
    February 2020
    January 2020
    December 2019
    November 2019
    October 2019
    September 2019
    August 2019
    July 2019
    March 2019
    November 2018
    October 2018
    September 2018
    August 2018
    June 2018
    March 2018
    February 2018
    January 2018
    December 2017
    November 2017
    August 2017
    July 2017
    April 2017
    March 2017
    February 2017
    January 2017
    November 2016
    October 2016
    September 2016
    August 2016
    July 2016
    June 2016
    May 2016
    April 2016
    March 2016
    January 2016
    November 2015
    October 2015
    September 2015
    August 2015
    July 2015
    June 2015
    May 2015
    April 2015
    March 2015
    February 2015
    January 2015
    December 2014
    November 2014
    October 2014
    September 2014
    August 2014
    July 2014
    June 2014
    May 2014
    April 2014
    March 2014
    February 2014
    January 2014
    December 2013
    November 2013
    October 2013
    September 2013
    August 2013
    July 2013
    June 2013
    May 2013
    April 2013
    March 2013
    February 2013
    January 2013
    December 2012
    November 2012
    September 2012
    August 2012

    Categories

    All
    Edge
    Exchange 2013
    Hybrid
    Lpe
    Lync 2010
    Lync 2013
    Mobility
    Oauth
    Office365
    Polycom
    Ucs

    RSS Feed

    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