The Lync Edge Server is an often misunderstood server role that in theory is not all that complicated.  But without knowing some of the basic functionality provided it can be confusing at times to understand what traffic is going where in the topology.

This article takes a look at the services and network traffic which travels to, and through, the Edge Server in an effort to simplify deployment and troubleshooting by gaining a basic understanding of the Edge Server’s purpose.

Edge Services

Before looking at the individual ports it is important to understand that the Edge Server is comprised of five different Windows Services which are responsible for handling different types of traffic and requests.

To identify the services and their names perform either of the following actions:

  • On the Edge Server open the Windows Command Prompt and issue the “net start | findstr Lync” command to list the installed services on the Lync Edge Server.

net start | findstr Lync


  • Or use the Services Control Panel applet to view the installed services.


When troubleshooting it is helpful to know the basic Service Name and well as the core application for each of the Edge services.

Display Name Service Name Service Executable
Lync Server Access Edge RTCSRV RTCSrv.exe
Lync Server Audio/Video Authentication RTCMRAUTH MRASSvc.exe
Lync Server Audio/Video Edge RTCMEDIARELAY MediaRelaySvc.exe
Lync Server Replica Replicator Agent REPLICA ReplicaReplicatorAgent.exe
Lync Server Web Conferencing Edge RTCDATAPROXY DataProxy.exe


Listening Port Allocation

The following diagram is a slight modification from the Port Summary for Single Consolidated Edge documentation in TechNet.  The Reverse Proxy server was removed as well as the outbound connections for DNS and HTTP, leaving only the inbound listening ports required on the Edge Server depicted.


As shown above there are multiple ports utilized by the Edge server with some of the same port numbers (e.g. 443) assigned to multiple interfaces.  Simply looking at the port number alone is not enough to know what type of traffic might be associated with it as different services will use the same port number for different purposes, albeit on different IP addresses as no two services can occupy the same listening port on the same IP address.  Thus it is important to always note the IP address of the interface as well as the port.  For example, traffic sent to the internal IP of the Edge server over port 443 would be for relaying media, but traffic sent to the Access Edge external IP over port 443 would actually be external client SIP signaling requests.

Example Configuration

For the remainder of this article the following Lync Server Topology is used throughout all example text and screenshots.

Role IP Address Fully Qualified Domain Name
Lync Front End Server lyncfe.domain.local
Lync Director lyncdir.domain.local
Internal Edge edge.domain.local
Access Edge
Web Conferencing Edge
A/V Edge


Querying Listening Ports

To verify that the proper ports are listening and the Edge services are functional the following validation checks can be performed.

  • On the Edge Server open the Windows Command Prompt and issue the “netstat -an” command to list all of the currently open network ports on all interfaces.  (The -a switch returns open listening ports as well as any ports with established connections.  The -n switch skips reverse name lookup on any host IP addresses and will allow the command to complete much faster.)

netstat -an


Among the results of all static and dynamic ports for any service or application on the server the specific Lync Server listening ports for the various Lync Edge services should be displayed. Note that some of these IP:Port combinations may display multiple entries as an active Edge server will have server and client connections. But the additional entries should all be reported as in an Established state and only a single line for each will be in a Listening state.

The following entries were pulled from the command output and listed in a table for easy identification.

Proto   Local Address             Foreign Address      State   
TCP                LISTENING
TCP               LISTENING
TCP              LISTENING
TCP              LISTENING
TCP              LISTENING
TCP              LISTENING
TCP             LISTENING
TCP             LISTENING
TCP             LISTENING
UDP            *:*
UDP          *:*

What the results above show are all of the static listening ports used by the various Lync in an unconnected Listening state. The Protocol is shown as TCP for all ports except for 3478 UDP on the A/V Edge external IP address which is used for connectionless traffic from Lync clients and servers to the Media Relay service. The Foreign Address of is shown as these are open listening ports with no connections established. Any established connections to these ports will be reported by netstat in additional lines.

The netstat command also provides a switch to display the executable name for each opened port to assist in identification of the which service owns which listening port.

  • On the Edge Server open the Windows Command Prompt and issue the “netstat –abn” command to display the same output as before but with additional lines showing the service program file name. (The -b switch adds the service names to the output for each port.  As shown in the example the individual switches can be concatenated so both -abn and -a -b -n are valid formats.)

netstat -abn


By matching up the reported executable names in the results the following table can be created, indicating what type of connections each port is listening for.

Local Address Interface Service Usage
TCP Internal
Replica Replicator Agent Inbound CMS replication traffic from internal Lync Servers
TCP Internal Audio/Video Edge [MediaRelaySvc.exe] ICE connections and tunneled media, desktop sharing, and file sharing from internal clients and servers
TCP Internal Access Edge [RTCSrv.exe] SIP connections from internal Lync servers
TCP Internal Audio/Video Authentication [MRASSvc.exe] A/V Authentication requests from internal servers
TCP Internal Web Conferencing Edge [DataProxy.exe] Web Conferencing (PSOM) connections from internal Lync servers
TCP External Access Edge [RTCSrv.exe] External client SIP registration and signaling traffic
TCP External Access Edge [RTCSrv.exe] Federation traffic from other OCS/Lync Servers, Public IM servers, and XMPP gateways.
TCP External Web Conferencing Edge [DataProxy.exe] External Web Conferencing PSOM data for client features like Whiteboarding, PowerPoint uploads, polls, and file uploads.
TCP External Audio/Video Edge [MediaRelaySvc.exe] ICE connections and tunneled media, desktop sharing, and file sharing from external clients and servers
UDP Internal Audio/Video Edge [MediaRelaySvc.exe] ICE connections and tunneled media from internal clients and servers
UDP External Audio/Video Edge [MediaRelaySvc.exe] ICE connections and tunneled media from external clients and servers


A closer look at the table above identifies some important concepts:

  • The CMS replication agent listens on all interfaces on the Edge server, presumable to assist in data replication in the event that the Edge Server configuration or routing is not configured to best practices.  In a proper deployment these connections would be coming from an internal Lync server directly to the Edge internal interface.
  • The Audio/Video Edge (Media Relay) services listens on both interfaces, as it must do so to proxy media connections between internally connected clients and external clients/servers.
  • The Web Conferencing Edge service also listens on both interfaces as it proxies web conferencing traffic between external clients and internal Front End servers.
  • The Audio/Video Authentication service listens only on the internal interface.  All client connections to this service are to provide dynamically assigned credentials to the Edge server to utilize ICE and access the media proxy as the Edge server will not accept connections from just any hosts.  Because the Access Edge Server cannot authenticate Lync users and must pass all authentication traffic through into the internal servers then it in turn also cannot authenticate ICE connections from these same users.  Thus call client ICE authentication attempts are proxied through an internal Lync server (Front-End or Director) which has already authenticated the client connection.  This means that all of these authentication attempts to the Edge Authentication service will always come from an internal Lync server, and not directly from any internal or external clients.  This is the reason that the A/V Edge FQDN (e.g. is not needed on the external Edge certificate as the internal Lync servers will connect to the internal Edge interface (e.g. using the internal Edge FQDN (e.g. edge.domain.local).

Media Port Range

If the listening ports in the table above are compared back to the original diagram there is still one last traffic type left unaccounted for: the 50,000-59,999 port range used for media traversal.

It is important to understand that this port range is only opened on the external A/V Edge interface, not the internal interface. All internal Lync clients and servers will tunnel media directly to either 3478 (UDP) or 443 (TCP). This many-to-one model is possible because of the deployment requirement that Network Address Translation (NAT) is not allowed between the internal Edge interface and any internal subnets hosting clients and servers. Thus every inbound connection to either 443 or 3478 would contain a unique IP address and source port.  Whereas on the external side of the Edge server the remote hosts could be behind NAT or multiple federated Edge servers could be attempting to open connections from the same source port.  In OCS R2 the ability to tunnel external media connections was added but this is only for UDP media and not TCP, thus is is still recommended to allow inbound connections form the Internet to this entire port range for both UDP and TCP traffic.

For a more detailed demonstration of exactly what these ports are used for and why it is recommended to still allow this range of ports inbound then jump to 1:04:00 of the Edge Media Connectivity with ICE technical session from TechEd 20102.

These ports are not constantly open for listening as they are allocated on-demand as the media relay service needs to.  When external and/or internal clients need to proxy media through the Edge Server then listening ports will be allocated during media negotiation between endpoints.  Once the best path for media has been established (which may not actually be through the Edge Server) then any unused ports where were allocated for that call are released.  When viewing port allocation with netstat a large number of ports between 50.000 and 59,999 may be displayed for both TCP and UDP protocols.


  • On the Edge Server open the Windows Command Prompt and issue the “netstat –anp tcp | findstr :5” command to return only listening and established TCP ports beginning with a 5.

netstat -anp tcp | findstr :5


  • On the Edge Server open the Windows Command Prompt and issue the “netstat –anp udp | findstr :5” command to list only listening and established UDP ports beginning with a 5.

netstat -anp udp | findstr :5


    Testing Listening Ports

    • From a remote host on an internal network (e.g. a Lync Front End Server) open the Windows Command Prompt and issue the telnet command to one of the internal Edge services.  (If the telnet client is not found then it must first be installed on the Windows Host.)

telnet edge.domain.local 5061

If a connection to the port fails this would indicate a problem like the service is not started or listening on the Edge server, the Edge server is unreachable due to a firewall or other port filtering or routing issue, or name resolution has failed.


    The expected response would be to see the command prompt window immediately refresh and a blank window will be displayed. (When testing connections to the internal IP to TCP 8057 for Web Conferencing a string of seemingly nonsensical characters will be turned instead of a blank window, this is normal.)



    • Leaving the telnet session open on the remote host move back to the Edge Server and issue the following command to look for the specific connection.

netstat -an | findstr 5061


    As this deployment includes a Director server ( existing established connections already appear to the Edge server over TCP 5061 from the assigned next-hop server, while the test telnet connection from the Lync Front End ( is easily identifiable in the results.

    This same test can be performed for any of the TCP listening ports on the Edge server, but not the UDP listening ports as the connectionless UDP protocol is not compatible with Telnet.  If it is attempted there will be no response from the server on the 3478 UDP ports listening on both sides of the Edge Server.

    A randomly selected TCP listening port in the 50,000-59,000 range can also be tested but the Edge Server will actively refuse the connection.  This result illustrates why the media range ports cannot be connected to or port-scanned under normal circumstances.

    • View the list of currently listening TCP ports and select one at random (e.g. 50137)


    • From a remote host attempt to telnet to that same port and see that the connection is refused almost immediately.


    This is because when the Telnet client connects it is neither the type of connection the Edge Server expects nor are the proper credentials available to provide to the media relay service to allow the connection to be established.

By Jeff Schertz

Site Administrator

72 thoughts on “Understanding Lync Edge Server Ports”
  1. Hi Jeff,

    Good write up. On the second last row of the table you’ve got UDP on the External interface, that should be Internal, right?


  2. Hi Jeff,
    Good Wwite up as always.

    Maybe you should mention that openning Inbound TCP/UDP 50000 to 59999 is for backward connection with OCS 2007 only…

    Since most company are on R2 or Lync, not opening those inbound ports usally calm down the firewall guys 🙂

    1. True that the 50k range is REQUIRED for OCS backward compatibility, that is not the only use for it. If the range is not open inbound then there are a few scenarios where the media path is less than ideal, like B2B Edge communications or DNS Load Balanced Edge arrays with NAT which could be forced to hairpin traffic and all have to utilize UDP tunneling directly between 3478. Watch the TechEd sessions linked in the article for more details on this.

  3. Great article Jeff as always. I have to do a lot of testing on Edge servers I'm building to verify that the customer has opened the firewall ports properly. I like to test the ports early on in the deployment process to give the firewall administrator and their change control policy time to fix problems. So I actually do my testing before I install the bits for the Edge server. To do this I use a tool called PortPeeker on the Edge. I can assign a specific IP and Port that PortPeeker will listen to traffic. I even do this with UDP. Yes, the UDP will not respond back to the testing machine, but I can see the traffic hit PortPeeker telling me I've won half the battle! Telnet works fine as a test client but I use the PortQueryUI based on the sysinternals PortQuery. I can fire a test and not have to try to break out of the Telnet window. PortQueryUI also let's me validate the DNS lookup as well as testing the port.

    Again great article and just some easy and free tools I use to hold the firewall administrator to the configuration fire!

  4. I wish I had read this post before we deployed it last summer.

    Thanks a lot. Another blog to subscribe in my reader.

    1. Desktop Sharing uses the same ports as audio or video but is only allowed over TCP and cannot utilize UDP.

  5. Hi ,

    Iam going to deploy lync 2010 enterprise edition in HA mode using radware alteon 5224. In my architecture i have 3 FE and 2 edge. can you please tell me how many HLB required. As per my knowledge we require 3 HLB i.e., 1 for FE , 1 for edge internal interface and 1 for Edge external interface. If am wrong please correct and is there any alternative ways to reduce the cost whn using HLB.

    Waiting for your reply


  6. Hi Jeff,

    Firstly, great article 🙂

    Is there a way for non-Lync SIP endpoints to use the MRAS service? I would like to use the Lync TURN server component (MediaRelaySvc.exe) without first registering a software-based SIP endpoint (that I have written) to the Lync edge server. I know an MRAS credential request must be sent to port 5062 in a SIP SERVICE message, but I believe the mras uri is only returned in the 200 OK response of the REGISTER message a Lync endpoint makes to the Lync edge server. If this MRAS uri can be found by an alternative means (Lync Server SDK etc.) please could you let me know?

    Awaiting your response,

    Simon Tolham

    1. I would doubt this as the Lync Edge server is only available for registered and federated connections.

  7. hello,

    thank you for all your work on Lync.

    Are you very sure the internal edge interface HAS TO BE ABLE to directly communicate with the internal clients (and vice versa)?

    I understand the internal edge interface communicates with the front end server (and then the front end server communicates with the internal clients).

    In every tutorials i've seen about configuring the edge server, people set up a permanent static route so the internal edge interface can communicate with the front end server. But in the case the internal clients are in multiple ip subnets (that might be common in large organizations i guess, anyway it's our case), do we have to configure a static route to every subnet where we might have internal lync clients? (and so on the firewall rule)

    I checked on our firewall, I found no packet log of clients trying to access directly the internal edge interface (and vice versa).

    I'm asking this because our Lync system working well (internally and externally in all possible ways, with webApp, Attendee, we usee public certfs, etc). Except that we can't make audio/video/sharing working with a federated organization (but presence and IM are working!).

    Our main log error message is following:
    federated call failed to establish due to a media connectivity failure where both endpoints are internal

    and we cannot figure what the problem does come from….

    1. Yes, internal Lync clients must be able to reach the internal Edge interface on at minimum 443 TCP and 3478 UDP for you to have any chance of tunneling media sessions between them and other remote clients. But the connections only need to be inbound, and most corporates typically allow all traffic over at least 43 outbound from internal trusted networks to a perimeter network. Often the UDP port is forgotten about which means that calls will still work (as will Desktop Sharing) but TCP media is designed as a fall-back method and properly supporting UDP is required for ideal real-time communications. You should be defining every internal subnet as a static route pointing toward the internal interface using only three simple commands which encapsulate all 10.0, 172.16-20, and 192.168 non-routable subnets. There is no need to create specific static routes for every unique internal subnet you may have defined. The fact that you can't get A/V and sharing to work with federated environments is your proof that this is required 🙂

      1. Are you very sure the internal edge interface HAS TO BE ABLE to directly communicate with the internal clients (and vice versa)?

        Just to add to Thomas point, Do we need port 5061 opened from all internal clients to internal Edge interface bi-directional ?

        1. Quite positive, although the communications are always initiated outbound so the internal clients will connect to the Edge internal IP over 443 TCP or 3478 UDP. The Edge server does not open inbound connections into the internal clients. Clients do not connect to the Edge over 5061. Only server-to-server is over 5061 TCP (Edge > Front End and Front End > Edge).

  8. thank you for your feedback.

    Actually, even with routing to every clients lans configured, a/v with federated users wasn't working.
    the thing is that we didn't installed the 'mediation server' (collocated to our frontend server in our case); after modifying the new topology and installing the new role on the frontend; it's now working like a charm with the federated users! 🙂

    I still notice one problem: we configured federation with Skype users as well.
    From Lync i can add skype users (IM is working) but from skype, i cannot add users from our Lync organization. It doesn't find the users in the skype directory. Moreover audio with skype users is working only with an internal computer with NAT access to the internet, it seems that the packets are not routed to the edge server; if the computer doesn't have access to the internet, the call doesn't establish… 🙁


    1. That is odd as the Mediation server plays no part in Lync-to-Lync media sessions. I think you still have some issue with your Edge Server deployment.

      1. so what is the purpose of the mediation server?
        i can confirm we weren't able to establish a/v call with our federated users without it.
        after installation of the (collocated) mediation service (we had none before), it began to work.

        1. The mediation server is used to route calls to a SIP tunnel or PSTN gateway as well as transcode wideband audio codes into G.711 for transmission over the PSTN. My guess is that while publishing the changes to your topology for the Mediation server something else may have changed or been updated.

  9. Hye! thanx for sharing this great article!
    i have also same problem THOMAs i cant use this , i cannot add users from our Lync organization. It doesn’t find the users in the skype directory. Moreover audio with skype users is working only with an internal computer …keep it up……

  10. Hi Jeff!

    I've followed your posts a lot and you´re actually famous Lync expert in Finland 🙂
    But I've now have a weird problem to which I can't seem to find solution.
    Everything is working great, we've Lync 2013 environment and Enterprise Voice except when user from another Lync domain is connected through a Lync conference… Then screen sharing doesn't work either way due to network problems. But if external guests join the meeting through web app they see screen share and can also share their screen…

    Any ideas?


    1. Can't say what the issue might be but it's most likely firewall related. Triple-check your configuration against the documented ports and protocols and keep a close eye on the TCP rules as Desktop Sharing is limited to TCP while (I assume) audio/video is working in these scenarios which utilize UDP first.

  11. Hi Jeff

    Big thanks !

    Having issues with joining web meetings initiated by external contacts. After accepting, internal traffic gets routed via the web proxy and fails due to content scanning. Is not the Web Conferencing part (PSOM) on the Edge server handling that traffic and what might be the reason why it fails to be routed correctly (autodiscover) ?
    It would be strange to exclude all external domains from content scanning if it really would need to go by the web proxy. I sense misconfiguration on our part and not something which would be designed that way, no?

    1. Sounds like a configuration issue to me but to be honest I'm not quite following. I'd suggest heading over to the TechNet support forums with some more details on your current configuration.

  12. Hi, I'm trying to diagnose problems with our edge server. I can connect from a mobile client to the edge and everything works fine but internal clients can't seem to go out through the edge. I can see the traffic from the client hitting the edge but then I can't see anything leaving the edge. I've tested all the firewall ports and they all seem fine. It's almost like the edge is just dropping the traffic instead of creating the request on.

    Any ideas?!

    1. Rob, that behavior is typically an indication of missing or incorrect network routes. Make sure that only the external Edge interface has a default gateway set and that you’ve added the required static, persistent routes for your internal networks. Also the mobile clients do not connect via Edge, they sign in using your reverse proxy. They only user the Edge server for media relay, so it’s possible your Edge deployment is not working at all.

  13. Hi Jeff

    Could you tell mie what is the port for External Data Sharing port: 8061 and If I should have it open?

    Thank you.

  14. Jeff, where is the internal Edge DNS record defined in the Lync topology? Some of our internal clients are connecting to the external facing A/V NIC on the Edge server and some are connecting to the internal consolidated NIC and I can’t figure out why. I suspect it’s because we do not have an internal DNS record for the internal facing NIC other than the FQDN of the Edge Server. But even if I create that record, I don’t know where to configure it inside of Lync 2013.

    1. You simply need to manually create an internal DNS Host record for the Edge internal FQDN. Because the Edge Server is not domain joined then it will not create a Dynamic DNS record in your AD DNS zone. The clients will always attempt a connection to the external AV IP address on your own Edge Server(s) as part of the SDP candidate connectivity check process during media establishment, but they should never actually send media to the external side. If TURN is required for a session then your internal Lync clients re hardcoded to send their media to the internal Edge interface (on 3468 UDP or 443 TCP).

      1. Jeff, having read your comment that client will always attempt connection to external AV IP address, what about access edge, and web? Today we are seeing that our clients can ping external access edge IPs, telnet to it on 443 and even send packets to external edge IP, captured in one of client logs. Is this a security risk and if it is how can we fix this issue?

        1. Internal clients will not use any of the external Edge interfaces. The AV interface can be ‘hit’ during candidate checks but it will not be used. Clients will not attempt connections to the SIP or Web conferencing ports when internal (unless the environment is incorrectly configured).

      2. Hi Jeff,

        Can the Internal interface of the Edge server be used to relay media between two internal clients that reside on different sites/subnets – but where these subnets IP address ranges overlap (therefore the clients IP addresses are NAT’d)?

        1. I don’t think so. You cannot NAT traffic between an internal LAN and the internal interface of the Edge Server. The clients may attempt to relay via the external Edge IP if they are not able to successfully connect to the Edge internal interface. I’ve never tested this though so my assumption could be wrong. Either way the clients will try every possible option to establish media, so while it may actually still work the path may not be ideal.

  15. Hello Jeff,
    Thank you very much for the very useful information found on your blog.
    I have an Edge server configure with 2 interfaces (Internal and External) but im experiencing the following issues :

    a) Can’t ping Internal Interface on Edge from the Lync server
    b) Can’t use Lync from outside (users working from outside the office)
    c) Lync Server Access service on the Edge server fails to start
    Systems Even Log error :
    The Lync Server Access Edge service terminated with service-specific error %%-2147014848.
    d) The Lyncserver (FE server) cant reached the inside

    Other questions:
    Should the address point to the Edge internal or external interface ?

    Thank you in advance sir.

    1. The address should point to your external Access Edge public IP address. The other errors are pretty critical so it sounds like a few pieces of your deployment are not correct.

  16. Jeff, We have deployed LYNC-2013 recently. We have used F5 in inline mode. We need to configure packet filters on F5 to tighten up the connections. Can you please list me the ports required from Edge Internal to Front end server.

  17. We are trying to get unencrypted outgoing calls from our lync to a SIP trunking provider.
    Lync is sending out the calls to port 5060 from an ephemeral port number.
    The SIP trunking provider sends back responses to that ephemeral port number.
    Our Lync support company is telling us that the SIP Trunking provider needs to send replies back to port 5060 instead of the ephemeral port number Lync sent the Invite from.
    Is that accurate?

  18. Hello Jeff,

    First of all thank you for your rich articles, I have an issue in my area, I have installed Skype for business server(FE) and Mediation server seperately, and configured sip trunk on Mediation server, now I do not have voice from my outbound, neither when I call from inbound nor when it calls to inbound. I tested your instructions, I can not telnet from FE to Edge server by the port of 5061, In the meantime we use tcp protocl with 5060 port for our sip trunk, I do not know what should I do. it takes too much time from me to troubleshoot, Please help me up.

    Thank you in advance for your prompt reply.

  19. Hi, Jeff- I’ve been using your articles and blogs since my company began its LS 2013 design/installation/deployment over a year ago and they’re incredibly useful!!! Thank you so much for providing these for the Lync community…

    I’ve followed this blog and all my ports seem to be opened and listening as expected. HOWEVER… (there’s almost always a “however”) when I initiate a Skype to Lync video call, or vice versa, the call lasts only 10 seconds or so then disconnects. Every time. Our topology is very vanilla: one FE std, one Edge, one Reverse Proxy behind a firewall, of course. All Lync systems are run on Hyper-V guests, each with 4 GB memory.

    Can you provide any suggestions on what might be happening or where I should start looking to troubleshoot and resolve this issue?

    Kindest Regards

    1. Steve, troubleshooting these types or issues are the most difficult. I would concentrate on the Firewall configuration, watching the logs in real-time to see what is happening after 10 seconds. I find that 90% of the issues i’ve run into in the past were due to the firewall configuration not being 100% correct.

  20. Hi Jeff,

    I love your article , finally someone introduced the application in network perspective.
    It helps network guy a lot!
    I have readed below aritcles which written by you.

    They are awsome , but I still have some questions.

    I am sure you already readed “Microsoft Lync Server 2013 Protocol Workloads”

    So my understanding, the internal users (inside corp network) can directly register to edger server or can register to front back server?

    Can you write a article regarding the topo(Microsoft Lync Server 2013 Protocol Workloads) from network perspective.
    Can you provide some packets capture how these protocol works?
    I know it will take a lot of times, I am willing to work with you to refine these lync articles and make a series lync aritcle.
    It’s so good such I want it better.



    1. Internal users do not ‘register’ to the Edge Server. Their registration is to the Front End server and they simply connect to the Edge server when needing to leverage ICE.

  21. I am hoping you still look at this blog. an issue regarding Lync ports. I can see all attempts at messaging from federated clients, but cannot respond. The federated partners show Presence Unknown to my internal clients, but their presence showing up in the Lync client of the federated partners. I see 443 traffic in the firewall to and from the Lync Edge server in the DMZ. But I do not see any 5061 traffic. We have been having trouble with the server, and as of last Friday AM the 5061 traffic was not sent by the Lync server any more, after a steady stream of 5061 traffic since the Edge server was set up. I have not changed any of the firewall rules. This system was working for 3 years.

    It is as if the Lync client does not even try to respond to the message. What would cause that?

  22. I am having an issue ans here is my configuration. I have a single edge server using a single IP and FQDN for the access edge Webconf and A/V services Ports
    access edge service Port 5061 FQDN
    Web Conferencing service Port 444 FQDN
    A/V service 443 FQDN
    I have good communication between my Intenal NIC on Edge serve and my Front End SFB server.
    The issue I am having when I test access from outside using SFB connectivity Analyzer it fails indicating the Certificate has an issue yet I can run an SSL Check on Ports 444 and 5061 from outside and all is good but when I run the same test on port 443 I get and error that there is not certificate or cannot connect using SSL. I have verified that the port 443 is open from outside by telnet to 443 from the internet to I have even gone to the extreme and opened all ports to the external NIC on the Edge server from the outside and still fails to verify SSL on port 443. I have reissued the Certificate multiple times with no luck. I started sniffing packets when running my SSL test and I get a TLS handshake hello but then nothing else it ends there. Any idea’s would be appreciated

    1. Hello Bill

      Did you solve your problem? I have the exact same constellation.
      I tried to connect to my newly installed edge server by a mac client. As I can see in the client protocol it tries to connect to the external ip using port 443. But this does not work as there is no certificate on that port.


      1. I fixed this problem. It was actually a missunderstanding:
        Windows clients are using the Edge Server when they connect from outside your organisation.
        Mobile and Mac clients are a different story. For those you need a Reverse Proxy because they use a differen Protocol to talk to your Skype for Business Servers (UCWA). There are some good step-by-step guides out there which explain how to set up a reverse proxy using nginx and Ubuntu. Use for example

  23. Hi Jeff.
    Could we expand upon this sentence:
    “All internal Lync clients and servers will tunnel media directly to either 3478 (UDP)”

    I can see all media streams using UDP 3478 to talk between our Edge server and internal clients.
    QoS does not seem to be implemented, with DSCP markings unset on all packets.

    Internally (between clients), we discriminate between audio and video on different UDP port ranges, setting DSCP to EF (audio) or AF41 (video) through Group Policy, depending on the port numbers.

    Yet all Edge streams use the same port, and the Edge server does not appear to mark any packets itself.
    Is there any way to implement QoS between Edge traffic and internal clients?


    1. No, the Edge server is meant to handle traffic between internal and external clients and the external clients are typically connected via the Internet. It ignores DSCP markings and does not tag them either.

      1. Jeff, thanks for all the great info, I’m really enjoying learning with your blogs.

        Cant quite understand the above statement.

        Are you say that due to the fact the packets arrived from the internet they can’t be QOS marked on the Edge for the traversal through the local network or WAN?

        Jamie said

        “talk between our Edge server and internal clients.”

        I assume this to mean the direction from edge to client is not being marked.

        Why not implement a local policy to mark all udp traffic with a source port of 3478?



  24. Mr. (Legendary Lync//Skype Guru) Shertz,
    I notice a little traffic (DMZ -> Inside) from the edge public NIC {MediaRelaySvc.exe) destined for private addresses. Some are IPs not in our LAN. (My edge server is multi-homed and has a route for that subnet to the LAN NIC) About 1000 users and only about 2000 packets /day from a handful (<20) addresses.

    My theories:
    -may be a user that is connected remotely via edge and public DNS. Then sleeps their machine, plugs in and DNS is caching public IP?
    That theory doesnt hold up when i see the traffic all day long 8-5.

    – the user is remote, connected to Skype before their VPN could connect and is connected through edge, but somehow when they send traffic to the edge it is responding to their private IP.

    Probably not enough to go one – but in short:
    Have you ever seen MediaRelaysvc.exe traffic from the DMZ NIC of a multi homed server going to internal IPs on ports 3478 and 5xxxx

    This was the only relevant search I came up with – besides your post… It does appear my internal DNS would be pointing to the public IP of the edge server but i have 0 internal DNS entries to the public IP of the Edge server. They all reference the internal IP.

    Thanks for your leadership in the Skype/Lync/Polycom communities!

  25. Hi Jeff,
    I am deploying a lync 2013 environment for IM, Presence only, do I need to the Edge Server? Should I only configure the reverse proxy to the front end server for the think client and mobile client?

    1. You’ll need both if you want to provide the needed functionality to any external and/or federated users. The Edge Server will facilitate IM communications and Presence information to federated users and also support any SIP-based Lync clients the ability to sign-in off-VPN. The mobile clients will only use the reverse proxy if you do not plan to support and media modalities.

  26. Hi, we have requirement for sfb online users to communicate over file sharing with external sfb client. How do we fulfill this. Please help

  27. Jeff, can’t tell you how many times I’ve referred back to your articles to help figure out what I’ve done wrong LOL. I’ve made so many fixes to my edge config and I have just about everything working properly except for one thing.

    When entering a meeting with a federated user (O365) – I finally got it to where we can share audio and video – but when anyone attempts screen sharing – we get a message about network errors, and occasionally get kicked out. You have any idea where I can start looking?

    1. When a/v works and content doesn’t the first thing I used to always look at was UDP vs TCP. With newer clients leveraging VBSS then that shouldn’t really be an issue, but RDP may still apply to the specific scenario you are testing.

  28. Hi Jeff,

    Thank you for Nice Article.

    1> Does On-Prem Exchange UM server required any Direct Connectivity to Skype EDGE server to access voice mail. If yes, What are the ports are required.

    2> If User Skype connected Via VPN, Does UM Voice Mail route via EDGE media relay. What is the media flow for Voice mail access for internal / VPN users

    1. No, the UM server communicates directly with the Skype for Business Front-End servers, it cannot communicate via and Edge server.

      And all media establishment via ICE works the same way: it will always attempt to establish a direct connection to the local IP of the other party. So if a VPN connection is available which allows direct routing between the two parties (for example a remote Skype client and the Exchange UM server) then that will be used, even if VPN is not ideal. The Edge Server would be used if no VPN was available and the media path would look the same as if the external Skype user was calling another Skype user located on the same internal network as the Exchange UM server. (The EUM server is basically an internal Skype ICE client.)

Leave a Reply to thomas Cancel reply

Your email address will not be published. Required fields are marked *