There are several ways in which we can utilize Audio/Video streams in Office Communications Server. While this article is based off of R2, the same “should… but not verified” work the same in OCS 2007 R1. There aren’t really any places out there that describe how the media session works in different circumstances. For example, what servers and ports are utilized when doing Audio/Video through the Live Meeting 2007 client when connected to the On-Premise Web Conferencing feature in OCS 2007 R2? 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 OCS 2007 R2 (the same applies for R1), 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. You can see what ports are used for OCS 2007 R2 here and here. This port range is utilized mainly for users who are internal to the network. 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 Group Policy to limit the amount of ports that are being used. 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\Com municator\Portrange\Enabled REG_DWORD 1
  • HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Com municator\Portrange\MaxMediaPort REG_DWORD 40039 (for example)
  • HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Com municator\Portrange\MinMediaPort REG_DWORD 40000 (for example)

Note: Both clients must have these registry keys set in order for the modified port range to take effect.
You must have at least 40 ports open which is an IETF Interactive Connectivity Establishment (ICE) protocol requirement to ensure that Audio/Video port negotiation works for peer to peer while internal to the network. ICE is a protocol that provides a mechanism for firewall or NAT traversal. The RFC draft for this protocol can be found here.
Audio/Video Connectivity Scenarios

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. UDP 3478 is tested first during ICE negotiation, and if that fails as a candidate, ICE will return 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, but if that fails during the ICE negotiation process, TCP 443 will be used as the ICE candidate. 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.
Issue to be aware of

Certain certificate vendors like to add www automatically to the CN of your certificate request with consent from the person requesting the certificate.
So for example, our certificate request for a regular certificate (non SAN) was CN=Servername.domain.com. These vendors provided the following certificate:

  • CN=Servername.domain.com
  • SAN=www.Servername.domain.com

Now this is where you can run into an issue when doing peer to peer and falling back to the internal Edge NIC or when one person is on the Internet and one person is internal while using Communicator. Some certificate vendors like to assign a www as a SAN name to your regular (non-SAN) cert. So if you requested a CN of Servername.domain.com, these vendors will automatically add www in front of your CN. This messes up peer to peer audio/video negotiation.
This is important to remember when getting a 3rd party certificate for the Internal Edge NIC. It is not supported to have anything other than a CN for this certificate. The reason why is ICE negotiation will not work properly. Because the www.servername.domain.com will be there as a SAN, the client will be provided the www.servername.domain.com name for ICE connectivity to the internal Edge NIC which will obviously fail. Because of this, the scenarios above which utilize the Internal Edge NIC will fail. To recap, the following two scenarios end up using the Internal Edge NIC:

  • One user internal to the network and one user external to the network
  • Internal users attempting to do peer to peer (media ports being closed) and falling back to the Internal Edge NIC

There are a few ways to fix/workaround the problem:

  • Use a Windows PKI implementation for Internal Edge NIC
  • Deal with the SAN name but use a CNAME for www.servername and redirect that to the servername HOST/A record.
  • If the vendor doesn’t add www to their SAN certs, you can get a SAN cert only with the CN filled out
  • Go with a different vendor that doesn’t automatically add www to their regular certificates.

Elan Shudnow



موضوعات مشابه: