Read the Office Communications Server 2007 R2 version of this article here.
There are several ways in which we can utilize Audio/Video streams in Lync Server 2010. If you have read my Office Communications Server 2007 R2 article, you will see the first part of this article will show that the methods in which you restrict ports and the amount of flexibility in Lync Server 2010 has vastly changed. You will also see that the second half of this article is identical to Office Communications Server 2007 R2 as the method in which clients connect is identical.
There aren’t really any places out there that describe how the media session works in different circumstances for Lync Server 2010. For example, what servers and ports are utilized when doing Audio/Video through legacy clients or Lync 2010 based clients. How do we configure Lync Server 2010 to restrict port usage for various modalities? How can we configure this for legacy clients? How can we configure this for native Lync Clients? How about when you do a peer to peer with both users being internal to the network? How about both users being external to the environment and connecting through the Edge? How about when you do a peer to peer with one user being internal and one user being external? Want to know? Read on…
Media Ports and Restricting Amount of Ports Being Used
The first thing to understand is that in Lync Server 2010, when a user attempts to activate any type of audio and/or video, they first attempt a peer to peer session. The ports utilized here are TCP/UDP 1024-65535. At least that’s what the documentation says as you can see here. This actually isn’t entirely true. If you do a Get-CSConferencingConfiguration you will actually see that they’re not using that entire range. It’s just that it’s supported to utilize that entire range. The ports that are actually utilized by default start at 5350. Later in this article, when we take a look at Set-CSConferencingConfiguration, we take a look at the default ports.
If you want users to utilize peer to peer audio while internal to the network, you must ensure that this port range is open even if users are in different sites. But what if you don’t want this entire port range open between your sites? You can utilize in-band provisioning to limit the amount of ports that are being used. This is very different than how it was configured in OCS 2007 R2. OCS 2007 R2 utilized Group Policies to set these options whereas in Lync, it uses Client Policies which in turn, provide Lync clients settings via in-band provisioning. You can read up on how Client Policies work on my previous article here.
In order to allow Lync to push the information on port restrictions to client’s, you must first enable Lync Server to do so by running the following command:
Set-CsConferencingConfiguration -ClientMediaPortRangeEnabled 1
Legacy Clients
When migrating to Lync Server 2010, you can use Lync 2010 Client or the Office Communicator 2007 R2 Client. When utilizing the OCS 2007 R2 infrastructure, you would use Group Policy to configure Media Port restrictions.
These two settings include:
- PortRange/MaxMediaPort
- PortRange/MinMediaPort
The above group policy settings modify the following three registry keys:
- HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Communicator\Portrange\Enabled REG_DWORD 1
- HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Communicator\Portrange\MaxMediaPort REG_DWORD 40039 (for example)
- HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Communicator\Portrange\MinMediaPort REG_DWORD 40000 (for example)
In Lync Server 2010, there is an equivalent property that provides this Media Port Range restriction to legacy clients. The Lync Server 2010 PowerShell cmdlet used is Set-CSConferencingConfiguration. So let’s take the above command and make sure that when upgrading to Lync Server 2010, Lync Server 2010 provides the legacy clients the same port restrictions:
Set-CSConferencingConfiguration -ClientMediaPort 40000 -ClientMediaPortRange 40
The above command will set the starting Media (audio/video/etc.) port to 40000 and allow the next consecutive 40 ports to be used for media. This will be the equivelant of 40000 as the MinMediaPort and 40039 as the MaxMediaPort. Again, this should be within the supported 1024-65535 range as mentioned earlier in this article.
Configuring Native Lync Clients Dynamic Port Ranges
Lync now has the ability to utilize different in-band provisioning settings for several different modalities; not just Audio/Video. The following are modalities you can separately configure port ranges for:
- Application Sharing:
Set-CSConferencingConfiguration -ClientAppSharingPort <beginning of port range (5350 by default)> -ClientAppSharingPortRange <extent of port range, at least 40 (40 by default)>
- Audio:
Set-CSConferencingConfiguration -ClientAudioPort<beginning of port range> -ClientAudioPortRange <extent of port range, at least 20 (40 by default)>
- Video:
Set-CSConferencingConfiguration -ClientVideoPort <beginning of port range> -ClientVideoPortRange <extent of port range, at least 20 (40 by default)>
- File Transfer:
Set-CSConferencingConfiguration -ClientFileTransferPort <beginning of port range> -ClientFileTransferPortRange <extent of port range, at least 20 (40 by default)>
- Dynamic SIP (Client Side SIP Ports):
Set-CSConferencingConfiguration -ClientSIPDynamicPort <beginning of port range> -ClientSIPDynamicPortRange <extent of port range, at least 20 (40 by default)>
As you can see, the first 4 modalities above are all set to have a default starting port of 5350 and use 40 ports. This is the recommended configuration and allows you to restrict all modalities to 40 ports which would the equivalent of what the configuration in OCS 2007 R2 would look like. It’s just now, you have more granularity should you decide the need to do so. You can certainly utilize a larger port range as needed or even use different port ranges for different modalities. Key thing to remember here is that in order to support QOS for clients, each modality needs to have a separate port range.
Note: For immediate application of these settings, service restarts are required.
Configuring Server Dynamic Port Ranges including QOS
The following three modalities are utilized by QoS:
- Application Sharing
- Audio
- Video
To ensure Port Ranges are restricted for QoS reasons, each modality above needs to be unique. By default, on a server, Audio and Video are already unique. Application Sharing is not. If Application Sharing QOS is not required, there is no need to change Application Sharing to utilize a unique port range.
For a Front End Server or a stand-alone A/V Conferencing Server:
Set-CsConferenceServer -Identity <ConferencingServer:FQDN of Lync Pool or A/V Server/Pool FQDN> -AudioPortStart <beginning of port range, 1024 or higher> -AudioPortCount <number of ports, at least 128> -VideoPortStart <beginning of port range, 1024 or higher > -VideoPortCount <number of ports, at least 128> -AppSharingPortStart <beginning of port range> -AppSharingPortCount <number of ports, at least 40>
For a Mediation Server:
Set-CsMediationServer -Identity <FQDN of Mediation Server or Mediation Pool> -AudioPortStart <beginning of port range> -AudioPortCount <number of ports>
For an Application Server:
Set-CsApplicationServer <ApplicationServer:FQDN of Lync Pool> -AudioPortStart <beginning of port range> -AudioPortCount <number of ports, at least 128> -AppSharingPortStart <beginning of port range> -AppSharingPortCount <number of ports, at least 128> -VideoPortStart <beginning of port range> -VideoPortCount <number of ports, at least 128>
For an Edge Server:
Set-CsEdgeServer -Identity: <FQDN of Edge Server (Single Edge) or FQDN of Edge Pool> -MediaCommunicationPortStart <beginning of port range, default 50000> -MediaCommunicationPortCount <number of ports, default 10000>
You can also configure dynamic port ranges for the Web Server functionality. This will not be beneficial from a QOS standpoint but rather will be beneficial if you want to restrict the ports down to a certain range. For example, if you wanted to lock your firewall down. The command for a Web Server would be:
Set-CSWebServer <FQDN of Web Server> -AppSharingPortCount <at least 100> -AppSharingPortStart <port start>
Audio/Video Connectivity Scenarios
The following list contains a list of media connection scenarios in Lync Server 2010. I do not talk about Media Bypass as I have written a previous article on it. In short, Media Bypass allows Lync 2010 client endpoints to communicate to a gateway via G.711 directly instead of sending the media to a Mediation Server. For more information on Media Bypass, please view my other article here.
Two Users Internal to the Network (media ports open)
When these two users are internal , they will attempt peer to peer. Because they can successfully connect to each other, they utilize peer to peer media. This is why OCS scales pretty high; because a lot of connections are one to one which means that peer to peer media connections are never bridged through the server. Because these users connect directly to each other for media, they have no need to connect to the Edge.
Note: The red arrow signifies a successful media connection only. The diagram does not reference any other signaling such as SIP.
Audio/Video through the Web Conferencing Server
When users are connected through On-Premise Web Conferencing and activate Live Meeting (when internal or external… doesn’t matter), they are connecting directly through the Front End’s Conferencing MCU’s. Because of this, even when it’s two users, the user’s are still connecting to the Front End MCUs. If both user’s are external, they still connect through the Front End MCUs but are proxied through the Edge Server.
Note: The red arrow signifies a successful media connection only. The diagram does not reference any other signaling such as SIP.
Two Users Internal to the Network and Any Users External to the Network
As previously stated, any time you have more than two users, peer to peer is no longer utilized and users always connect directly to the MCU on the Front End Servers. This means that both users internal to the network will connect to their Front End server(s) and the external user will connect to the Front End server as well utilizing the Edge Server for proxying to the Front End. There is absolutely no peer to peer connectivity in this situation.
Note: The red arrow signifies a successful media connection only. The diagram does not reference any other signaling such as SIP.
Two Users on the Internet
When these two users are external , they will attempt peer to peer. Because they can successfully connect to each other, they utilize peer to peer media. This is why OCS scales pretty high; because a lot of connections are one to one which means that peer to peer media connections are never bridged through the server. Because these users connect directly to each other for media, they have no need to connect to the Edge for Audio/Video. You will still see the user connected to the Access/Edge over port 443 and/or 5061 (if these are your remote access port and federation port if you are using federation). When users are connected through On-Premise Web Conferencing and activate Live Meeting, they are connecting directly through the Front End’s Conferencing MCU’s. The Front End will have a certificate that contains the Pool Name and will/can contain SAN names for additional SIP domains that you may contain. Because of this, SAN names are supported on Front End Servers.
Note: The red arrow signifies a successful media connection only. The diagram does not reference any other signaling such as SIP.
Two Users Internal to the Network (media ports closed)
When these two users are internal , they will attempt peer to peer. During their ICE negotiation, as previously stated, they will know the Internal Edge NIC in case their peer to peer connectivity fails. Because they fail to connect to each other, they will connect to the internal Edge NIC over either UDP 3478 or TCP 443. ICE has a mechanism where it will test a lot of candidates to see where connections should be made. ICE will test UDP 3478 and TCP 443 in parallel and if UDP 3478 works, the client will receive UDP 3478 due to it having less overhead. If UDP 3478 does not work, the client will receive TCP 443.
If you anticipate on blocking ports between your users, make sure your Edge Server can scale high enough to deal with the amount of Audio/Video connections it will be handling. To block one of your sites from doing peer to peer with other sites, block the peer to peer port range (discussed at the beginning of this article) from that site and block that site from communicating over UDP 3478 and TCP 443 to the Edge Server. This will prevent clients from doing any type of media communication from user’s outside of their own site. If you want to allow them to do peer to peer for users in some sites, modify the firewall ACLs accordingly for those sites.
Note: Diffserv markings for Quality of Service (QoS) are lost through an Audio/Video Edge Server.
Note: The red arrow signifies a successful media connection only. The diagram does not reference any other signaling such as SIP.
One User External and One User Internal
When one user is internal and one user is external , they will attempt peer to peer but not in the same sense as in two internal users. The external user will hit TCP 5061 to the Access Edge Server and will be provided with either UDP 3478 or TCP 443 for the Audio/Video Edge. As stated earlier, UDP 3478 is preferred even if the connection test for TCP 443 and UDP 3478 were successful in testing. If you attempt a telnet edgeserver.domain.com over the Internet, telnet will fail to connect. This is because telnet uses TCP. You can do a netstat -an to see your server listening on UDP 3478 and utilize a different program such as netcat which can attempt telnet to UDP by using netcat -u host 3478. More information on netcat here.
Moving on… we see that the user will connect to the A/V Edge over UDP 3478 or TCP 443, but what about the internal user? Because this is technically peer to peer, the internal user will NOT connect to the MCU on the Front End but will instead connect directly to the A/V Edge Server’s Internal NIC over UDP 3478 or TCP 443 as well. The Front End A/V MCU will not be used in this scenario. When you add a 3rd person to the conversation, the external user will connect to the Front End Server’s A/V MCU in which the A/V Edge will proxy this data for the user, and the internal users will connect to the Front End A/V MCU instead of the Internal Edge NIC.
Note: Diffserv markings for Quality of Service (QoS) are lost through an Audio/Video Edge Server.
Note: The red arrow signifies a successful media connection only. The diagram does not reference any other signaling such as SIP.
Elan Shudnow :: Dec.06.2010 :: Lync 2010 :: 46 Comments »
