Lync Edge Server Port Ranges and QoS
Ran into this and felt like until the documentation is updated, I should call this out. On this Technet article, it shows you how to configure port ranges for Edge Servers in Lync Server 2013. In the hopeful case that this page is updated, here is a static image:
The issue with this article is that it appears to tie the port ranges for the Edge server to QoS which is not the case. You need to read the article very carefully. The first sentence in it tells you that you do not need to configure separate port ranges for Audio/Video/Application Sharing on the Edge. It then goes on to tell you how to change the port ranges to match up with what you may have set for your front-end servers.
The problem with this is that you are changing the ports that the Edge will/can communicate on. If you are following Microsoft’s firewall guidance on ports, you should be allowing the 50,000-59,999 port range (TCP and UDP) outbound. If you follow this example, you would need to allow the range 40,803-65,533 (TCP and UDP) outbound.
The article claims you might do this to make administration easier but I will claim just the opposite. Based on what most Lync admins know and what Microsoft states are the default ports, without some really good documentation and knowledge transfer, you are probably setting up a future admin to fail.
If you are wondering what happens when you set this like this but only allow the 50k port range outbound from the Edge servers, here is your answer. When an outside user attempts to call a user who is inside or join a conference, the client will send an Invite that contains SDP candidates. Those candidates will have ports associated with them based on the configuration. The external client will attempt to connect on ports outside of the 50k range that is being allowed on the firewall (i.e. 40,080-49,999 or 60,000-65,533). These connections will fail and the call will fail to establish. On a conference call, this can be seen as the user connecting and disconnecting from the conference several times in just a few seconds.
Many kudos to @tompacyk for helping me see what was happening here.
phyler's blog 
Its really a shame what most of the guys @MS Lync Document team are doing. Seriously, 2.5 years have already passed (for the record as Lync server 2013 was released in Sept 2012) and the official documentation is still full of crap. I mean, its not some hidden, extremely hard to encounter mistake! No! Its exactly the opposite: this is the most customerfacing-critical part of every design: network ports used by their damn product in the DMZ, where all firewall admins are like crazy paranoid, and will literally block anything else that was not explicitely asked on the paper.
Poor quality job, MS, poor quality! Clearly shows that there is not a single intelligent leader person inside that whole team who would spend a couple of weeks of time and go thorough the entire document, and challenge the writers of each chapters for their mistakes.
I am more than sure, that worldwide IT community has already identified all these document mistakes, and keep this info in secret from the rest of the world. Thatswhy it is important for MS to fix these mistakes ASAP, so that people who cannot afford a whole department of engineering to investigate mistakes in the vendor specifications could also have access to technically correct information.
Yeah, it was a pretty scary moment when we realized what had happened and why. They try to tie two things together that aren’t even related. If you aren’t carefully reading the rest, this becomes just a blanket copy and paste effort. I wonder how many people have random conference join issues due to this and don’t even know it?
I guess you sent a mail to lyncdoc2013@microsoft.com with the feedback. Let me tell you: its futile to send them any feedback. They dont read them, dont act on them, they simply dont care.
Yes, it did get reported last week. Hopefully that page will change. That is why I took the screenshot. I have seen changes happen so I’m hopeful.