Desktop sharing is not working with one federated client

Hi

Please check that you are allowing ports 50000-59999 TCP and UDP in both directions between your AV Edge interface and the Internet.

Also check that the correct public IP has been published to the AV Edge NAT Address in the topology builder.

Check the federated partner has also done the above.

Check that your firewall is not performing deep packet inspection on the AV IP too. If it is trying to check for a certificate it cannot because there is no certificate on the AV service by design.

thanks

August 12th, 2015 5:01am

Hi,

We are facing desktop sharing issue with federated client in lync.

error in monitoring server :-

 From user agent: UCCAPI/15.0.4701.1000 OC/15.0.4701.1000 (Microsoft Lync)  
  Diagnostic header: 25; reason="A federated call failed to establish due to a media connectivity failure where both endpoints are internal"; UserType="Callee"; MediaType="application-sharing"; ICEWarn="0x900029"; LocalSite="10.98.128.9:53137"; LocalMR="172.29.55.190:443"; RemoteSite="10.35.17.5:57483"; RemoteMR="96.11.125.102:59043"; PortRange="53001:54500"; RemoteMRTCPPort="59043"; LocalLocation="2"; RemoteLocation="2"; FederationType="0"; NetworkName="xyz.com"; Interfaces="0x2"; BaseInterface="0x2"; BaseAddress="10.98.128.9:54047; MrDnsE="av.xyz.com"; MrResE="0"; MrDnsI="edge.xyz.com"; MrResI="1"; LyncAppSharingDebug="ViewerChannel:0x0; Memory Usage: totalUsedVirtual=706, availableVirtual=8387901; AutoRejoin=0; StartupTime: 2015-08-11T13:07:11.999Z; "

Any idea...

Thanks,

Deepak

Free Windows Admin Tool Kit Click here and download it now
August 13th, 2015 2:38am

Hi,

Base on your description above, the issue only happen with one federated partner.

If it is the case, the issue may happen on the Edge of partner side.

Conferencing Media Establishment (Federated):  CustomerA IS federated with CustomerB. CustomerB creates a Lync meeting and sends it to CustomerA. CustomerA joins the meeting.

  1. Customer A is joining using the Lync 2010 client CustomerA (attendee) will connect to CustomerA's Edge then to CustomerB's (organizer) Edge and finally onto the MCU provisioned for the meeting from the organizer pool
    1. Calling Party (attendee) <-> CallingPartyEdge (attendee Edge) <-> CalledPartyEdge (organizer) <-> MCU (organizer)
  2. Customer A is joining using the Lync 2013 client - CustomerA will try to tunnel media traffic to its own Edge which will then do FTURN with CustomerB's Edge. If the FTURN is successful, the media will be between CompanyA's Edge and CompanyB's Edge on 3478 -3478 for audio and 50k source to 443 destination for desktop sharing. If FTURN fails then media between the Edge servers will try to use 50k range ports.
    1. Calling Party (attendee) <-> CalledParty (AV MCU) - Unlikely, but possible. The non-Federated user would have to be internal to the network where the conference is hosted
    2. Calling Party (attendee) <-> CallingPartyEdge<->CalledParty (AV MCU) - Very unlikely. Would mean the AV MCU can directly connect to 50k of the attendee Edge
    3. Calling Party (attendee) <-> CallingPartyEdge<->CalledPartyEdge<-> AV MCU (organizer) - FTURN this is the most common scenario that would work.
    4. Calling Party (attendee) <->CalledPartyEdge<-> AV MCU (organizer) - If attendee can connect directly to 50k of the AV MCU Edge

So please check if the 50,000-59,999 ports open on both Edge Servers external interface for your corporation and the partner corporation.

More details:

http://blogs.technet.com/b/rischwen/archive/2015/04/13/federation-call-flow-skype-for-business-and-lync-clients.aspx

Best Regards,
Eason Huang

August 13th, 2015 3:44am

Hi,

Higher port is open both edge servers.

I am getting below error also :-

Diagnostic header:

25; reason="A federated call failed
to establish due to a media connectivity failure where both endpoints are
internal"; LyncAppSharingDebug="SharerChannel:0x0; Memory Usage:
totalUsedVirtual=638, availableVirtual=8387969; StartupTime:
2015-08-12T12:48:01.358Z; "

Thanks,

Deepak

Free Windows Admin Tool Kit Click here and download it now
August 14th, 2015 7:51am

Usually you get this problem when from the edge internal interface their is no static route to the client subnet. If there is, there may be internal firewalls blocking edge => LAN traffic and vice versa
August 14th, 2015 7:55am

Great advice already on the thread.

I wanted to just throw something in - most of the traffic that you are seeing uses UDP.  However, desktop/app sharing uses TCP.   So, when I saw this issue in the past, the only difference was "UDP works, but something is causing TCP to fail."    In my experience, I had an asynchronous route that was causing my issue - we had an MPLS link (e.g. ETH1) and we had an Internet link (e.g. ETH2).   SiteA had a route going to SiteB through the MPLS, however, SiteB had a route going back to SiteA through the Internet.   Therefore, when TCP sends the ACK - the switch sent a RESET on the TCP session.   The error was "Transmit send on ETH1 but ACK received on ETH2 so RST the session".   No doubt you have a network config issue -  but you should do some wireshark traces and see if you get any resets on the TCP.

Either way, it appears that TCP is the thing that's dying - from the limited information available.


Free Windows Admin Tool Kit Click here and download it now
August 14th, 2015 8:51am

Great advice already on the thread.

I wanted to just throw something in - most of the traffic that you are seeing uses UDP.  However, desktop/app sharing uses TCP.   So, when I saw this issue in the past, the only difference was "UDP works, but something is causing TCP to fail."    In my experience, I had an asynchronous route that was causing my issue - we had an MPLS link (e.g. ETH1) and we had an Internet link (e.g. ETH2).   SiteA had a route going to SiteB through the MPLS, however, SiteB had a route going back to SiteA through the Internet.   Therefore, when TCP sends the ACK - the switch sent a RESET on the TCP session.   The error was "Transmit send on ETH1 but ACK received on ETH2 so RST the session".   No doubt you have a network config issue -  but you should do some wireshark traces and see if you get any resets on the TCP.

Either way, it appears that TCP is the thing that's dying - from the limited information available.


  • Edited by Greg Seeber Friday, August 14, 2015 12:51 PM
August 14th, 2015 12:50pm

Great advice already on the thread.

I wanted to just throw something in - most of the traffic that you are seeing uses UDP.  However, desktop/app sharing uses TCP.   So, when I saw this issue in the past, the only difference was "UDP works, but something is causing TCP to fail."    In my experience, I had an asynchronous route that was causing my issue - we had an MPLS link (e.g. ETH1) and we had an Internet link (e.g. ETH2).   SiteA had a route going to SiteB through the MPLS, however, SiteB had a route going back to SiteA through the Internet.   Therefore, when TCP sends the ACK - the switch sent a RESET on the TCP session.   The error was "Transmit send on ETH1 but ACK received on ETH2 so RST the session".   No doubt you have a network config issue -  but you should do some wireshark traces and see if you get any resets on the TCP.

Either way, it appears that TCP is the thing that's dying - from the limited information available.


  • Edited by Greg Seeber Friday, August 14, 2015 12:51 PM
Free Windows Admin Tool Kit Click here and download it now
August 14th, 2015 12:50pm

Great advice already on the thread.

I wanted to just throw something in - most of the traffic that you are seeing uses UDP.  However, desktop/app sharing uses TCP.   So, when I saw this issue in the past, the only difference was "UDP works, but something is causing TCP to fail."    In my experience, I had an asynchronous route that was causing my issue - we had an MPLS link (e.g. ETH1) and we had an Internet link (e.g. ETH2).   SiteA had a route going to SiteB through the MPLS, however, SiteB had a route going back to SiteA through the Internet.   Therefore, when TCP sends the ACK - the switch sent a RESET on the TCP session.   The error was "Transmit send on ETH1 but ACK received on ETH2 so RST the session".   No doubt you have a network config issue -  but you should do some wireshark traces and see if you get any resets on the TCP.

Either way, it appears that TCP is the thing that's dying - from the limited information available.


  • Edited by Greg Seeber Friday, August 14, 2015 12:51 PM
August 14th, 2015 12:50pm

Hi,

thanks your sharing your experience,

Let me explain the my scenario :-

We have two sites (Location) site A and Site B.

In site A, We have Lync infra (FE,Edge, etc) and site B is connected with MPLS to site A.

we have Lync federation with other company and also AD trust with federated company. Federated company Lync infra site is connected with site A with VPN tunnel.

Now

when site A user do the Lync conference with federated client then conference works fine without any issue.

But with the site B user do the conference with federated client then desktop sharing does not work.

Lync error :-

Diagnostic header: 25; reason="A federated call failed to establish due to a media connectivity failure where both endpoints are internal"; LyncAppSharingDebug="ViewerChannel:0x0; Memory Usage: totalUsedVirtual=647, availableVirtual=8387960; AutoRejoin=0; StartupTime: 2015-08-14T12:00:13.504Z; "

Edge Netmon :-

11803 6:36:46 PM 8/14/2015 52.9369640 MediaRelaySvc.exe 96.x.x.12 172.x.x.13 TCP TCP:Flags=...A.R.., SrcPort=50486, DstPort=HTTPS(443), PayloadLen=0, Seq=2307065106, Ack=3099001451, Win=0 {TCP:985, IPv4:917}

any idea...

Thanks,

Deepak

Free Windows Admin Tool Kit Click here and download it now
August 18th, 2015 7:52am

Hi,

From your description above, the issue may happen between the network of Site A and Site B. Please double check you open the needed ports between Lync users who homed at Site B and the Edge Server in Site A. Also there is static route between Lync users at Site B and the internal interface of the Edge Server in Site A.

Best Regards,
Eason Huang

August 24th, 2015 4:53am

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics