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
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=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
Internal Routing
One of the common causes of edge calls failing is that clients on the internal network are not completely reachable by the internal network interface of the Edge server. Since only the Edge server's external network interface contains the default gateway, this means that all internal routes must be properly defined for the internal network interrace using the "route add" command. Most companies will use the private IP addressing range as defined by by RFC 1918 for IPv4 so the following route add commands should do the trick:
>route add 10.0.0.0 mask 255.0.0.0 <gateway IP for internal network> /p
>route add 172.16.0.0 mask 255.240.0.0 <gateway IP for internal network> /p
>route add 192.168.0.0 mask 255.255.0.0 <gateway IP for internal network> /p
One of the common causes of edge calls failing is that clients on the internal network are not completely reachable by the internal network interface of the Edge server. Since only the Edge server's external network interface contains the default gateway, this means that all internal routes must be properly defined for the internal network interrace using the "route add" command. Most companies will use the private IP addressing range as defined by by RFC 1918 for IPv4 so the following route add commands should do the trick:
>route add 10.0.0.0 mask 255.0.0.0 <gateway IP for internal network> /p
>route add 172.16.0.0 mask 255.240.0.0 <gateway IP for internal network> /p
>route add 192.168.0.0 mask 255.255.0.0 <gateway IP for internal network> /p
RSS Feed