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

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:

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.

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

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.

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:

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:

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:

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

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:

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

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

Next, select the appropriate IP options and enter the 3 FQDNs of the external interface as defined earlier:

Next, enter the Edge internal IP address and click "Next" followed by the external IP address and click "Next":

Specify the next hop server to be the legacy Lync2010 FE at this stage. Migration to the new Lync2013 pool will be done later:

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:

Publish the topology and verify successful completion:

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

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"

After determining the deployment state, click "Run" in "Step 1. Install Local Configuration Store":

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

Click "Finish" when the Local Configuration Store installation is completed. Next click in "Run" in "Step 2 Setup or Remove Lync Server Components".

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:

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:

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

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:

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:

Next, download the certificate and save locally to a file:

Then, back on the Lync Certificate Wizard, click on "Import" to import the downloaded certificate file:

In the "Import Cerfificate" wizard, select the saved certificate file and click "Finish" to completed the wizard:

After importing the certificate, we need to click on "Assign" in the certificate wizard:

In the Certificate Assignment wizard, we click "Next" and "Finish" to complete the assignment:

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

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:

In the Subject Names windows, note that the two SANs are already added automatically:

An additional step is required to select the SIP domain to be added to the SAN list:

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

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:

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

In the "Certificate Assignment" window click "Next". In the "Certificate Store" window, select the external certfiicate and click "Next":

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:

Finally, we start the services by clicking "Run" at the "Start Services":

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.