locked
Desktop sharing is not working with one federated client RRS feed

  • Question

  • 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

    Wednesday, August 12, 2015 6:35 AM

Answers

  • 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


    Please remember to mark the replies as answers if they help, and unmark the answers if they provide no help. If you have feedback for TechNet Support, contact tnmff@microsoft.com.

    Eason Huang
    TechNet Community Support

    • Marked as answer by Eason Huang Monday, September 7, 2015 3:16 AM
    Monday, August 24, 2015 8:51 AM

All replies

  • 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


    Note: Please remember to `Mark as Answered` a post that answers your question and/or `Vote as Helpful` posts that have helped you. This will help others find answers to similar problems. For more Skype for Business help visit: http://www.skype4b.uk Please note that answers are based on my experience and opinion only and do not necessarily represent the views of my employer.

    • Proposed as answer by Eason Huang Thursday, August 13, 2015 7:09 AM
    Wednesday, August 12, 2015 9:00 AM
  • 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


    Please remember to mark the replies as answers if they help, and unmark the answers if they provide no help. If you have feedback for TechNet Support, contact tnmff@microsoft.com.

    Eason Huang
    TechNet Community Support

    Thursday, August 13, 2015 7:41 AM
  • 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

    Friday, August 14, 2015 11:50 AM
  • 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

    Note: Please remember to `Mark as Answered` a post that answers your question and/or `Vote as Helpful` posts that have helped you. This will help others find answers to similar problems. For more Skype for Business help visit: http://www.skype4b.uk Please note that answers are based on my experience and opinion only and do not necessarily represent the views of my employer.

    Friday, August 14, 2015 11:54 AM
  • 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
    Friday, August 14, 2015 12:50 PM
  • 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

    Tuesday, August 18, 2015 11:50 AM
  • 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


    Please remember to mark the replies as answers if they help, and unmark the answers if they provide no help. If you have feedback for TechNet Support, contact tnmff@microsoft.com.

    Eason Huang
    TechNet Community Support

    • Marked as answer by Eason Huang Monday, September 7, 2015 3:16 AM
    Monday, August 24, 2015 8:51 AM