Understanding Lync Edge Server Ports

July 5, 2012 by · 53 Comments 

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

image

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

image

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.

image

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 10.2.10.25 lyncfe.domain.local
Lync Director 10.2.10.27 lyncdir.domain.local
Internal Edge 10.4.5.11 edge.domain.local
Access Edge 140.2.21.9 sip.domain.com
Web Conferencing Edge 140.2.21.10 webconf.domain.com
A/V Edge 140.2.21.11 av.domain.com

 

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

image

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     0.0.0.0:4443              0.0.0.0:0            LISTENING
TCP     10.4.5.11:443             0.0.0.0:0            LISTENING
TCP     10.4.5.11:5061            0.0.0.0:0            LISTENING
TCP     10.4.5.11:5062            0.0.0.0:0            LISTENING
TCP     10.4.5.11:8057            0.0.0.0:0            LISTENING
TCP     140.2.21.9:443            0.0.0.0:0            LISTENING
TCP     140.2.21.9:5061           0.0.0.0:0            LISTENING
TCP     140.2.21.10:443           0.0.0.0:0            LISTENING
TCP     140.2.21.11:443           0.0.0.0:0            LISTENING
UDP     10.4.5.11:3478            *:*
UDP     140.2.21.11:3478          *:*

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 0.0.0.0:0 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

image

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 0.0.0.0:4443 Internal
External
Replica Replicator Agent Inbound CMS replication traffic from internal Lync Servers
TCP 10.4.5.11:443 Internal Audio/Video Edge [MediaRelaySvc.exe] ICE connections and tunneled media, desktop sharing, and file sharing from internal clients and servers
TCP 10.4.5.11:5061 Internal Access Edge [RTCSrv.exe] SIP connections from internal Lync servers
TCP 10.4.5.11:5062 Internal Audio/Video Authentication [MRASSvc.exe] A/V Authentication requests from internal servers
TCP 10.4.5.11:8057 Internal Web Conferencing Edge [DataProxy.exe] Web Conferencing (PSOM) connections from internal Lync servers
TCP 140.2.21.9:443 External Access Edge [RTCSrv.exe] External client SIP registration and signaling traffic
TCP 140.2.21.9:5061 External Access Edge [RTCSrv.exe] Federation traffic from other OCS/Lync Servers, Public IM servers, and XMPP gateways.
TCP 140.2.21.10:443 External Web Conferencing Edge [DataProxy.exe] External Web Conferencing PSOM data for client features like Whiteboarding, PowerPoint uploads, polls, and file uploads.
TCP 140.2.21.11:443 External Audio/Video Edge [MediaRelaySvc.exe] ICE connections and tunneled media, desktop sharing, and file sharing from external clients and servers
UDP 10.4.5.11:3478 Internal Audio/Video Edge [MediaRelaySvc.exe] ICE connections and tunneled media from internal clients and servers
UDP 140.2.21.11:3478 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. av.domain.com) is not needed on the external Edge certificate as the internal Lync servers will connect to the internal Edge interface (e.g. 10.4.5.11) 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

image

  • 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

image

    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.

    image

    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.)

    image

    image

    • 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

image

    As this deployment includes a Director server (10.2.10.25) 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 (10.2.10.27) 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)

    image

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

    image

    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.

About Jeff Schertz
Site Administrator

Comments

53 Responses to “Understanding Lync Edge Server Ports”
  1. @widgetNinja says:

    Great post Jeff, thanks for your diligence!

  2. Steve says:

    Awesome article Jeff!

  3. bob says:

    Jeff:

    Great article!

    Did you include Web Components in your illustration?

    BK

  4. Al says:

    Hi Jeff,

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

    Al

  5. Mark Tanguay says:

    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 🙂

    • jeffschertz says:

      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.

  6. John Miller says:

    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!

  7. gamr says:

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

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

  8. Rodrigo says:

    Hi Jeff,

    What port an external user uses for desktop sharing with an internal lync user?

  9. In the "Media Port Range" section, in the grey graphic area is a typo:
    netstat -anp ucp | findstr :5
    should be
    netstat -anp udp | findstr :5
    UDP not UCP

  10. vijendhar says:

    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

    Regards
    Vijendhar.A

  11. Simon Tolham says:

    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

    • jeffschertz says:

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

  12. thomas says:

    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….

    • jeffschertz says:

      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 🙂

      • Shady says:

        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 ?

        • jeffschertz says:

          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).

  13. Thomas says:

    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… 🙁

    Regards,

    • jeffschertz says:

      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.

      • Thomas says:

        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.

        • jeffschertz says:

          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.

  14. easy cms says:

    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……

  15. Arvind Tembhurne says:

    Great post, Jeff.

  16. Tom says:

    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?

    Thanks!

    • Jeff Schertz says:

      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.

    • Jeff Schertz says:

      That sounds like it may be related to TCP media relay between your Edge and federated Edge Servers.

  17. Lyncer says:

    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?

    • Jeff Schertz says:

      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.

  18. Rob says:

    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?!

    • Jeff Schertz says:

      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.

  19. Olo says:

    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.

  20. Mark H says:

    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.
    Thanks

    • Jeff Schertz says:

      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).

      • OA says:

        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?

        • Jeff Schertz says:

          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).

  21. Rodrigo says:

    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 sip.domain.com point to the Edge internal or external interface ?

    Thank you in advance sir.
    Respectfully,
    Rod

    • Jeff Schertz says:

      The sip.domain.com 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.

  22. Ganesh says:

    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.

  23. James Thompson says:

    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?

  24. Alex says:

    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.

  25. Steve says:

    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

    • Jeff Schertz says:

      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.

  26. Durant says:

    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.

    http://blog.schertz.name/2012/10/lync-edge-stun-turn/
    http://blog.schertz.name/2012/07/understanding-lync-edge-server-ports/

    They are awsome , but I still have some questions.

    I am sure you already readed “Microsoft Lync Server 2013 Protocol Workloads”
    https://technet.microsoft.com/EN-US/library/dn594589(v=ocs.15).aspx

    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.

    Regards,

    Durant

    • Jeff Schertz says:

      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.

Trackbacks

Check out what others are saying about this post...
  1. […] Lync Edge Server Ports : Jeff Schertz’s Blog Posted on July 5, 2012 by johnacook http://blog.schertz.name/2012/07/understanding-lync-edge-server-ports/ Share this:StumbleUponDiggRedditLike this:LikeBe the first to like […]

  2. […] updated since OCS to provide for a simpler certificate configuration.  (The previous article Understanding Lync Edge Ports goes into further detail on these Edge […]

  3. […] Additional Reading / Resources: Lync Edge – Choosing a Topology Scaled Consolidated Edge, DNS Load Balancing with Private IP Addresses Using NAT Understanding Lync Edge Server Ports […]



Speak Your Mind

Tell us what you're thinking...
and oh, if you want a pic to show with your comment, go get a gravatar!