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
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
2 Comments
Baf
11/13/2013 06:29:23 pm

Hi!

But why 443 port is not sufficient? Why do we need 3478?

Reply
Naren
10/11/2014 06:42:19 am

it required to authenticate with server SSL certificate.

Reply

Your comment will be posted after it is approved.


Leave a Reply.

    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