OCS 2007 R2 – External Audio/Video Conferencing Issues

The successful implementation of external audio/video conferencing in Microsoft OCS 2007 R2 appears to be an issue that many people face when deploying the product. I too have experienced this issue and this post will detail both the errors and resolutions put in place to enable external A/V conferencing on an OCS 2007 R2 Standard Edition deployment with a Consolidated Edge server. The implementation item’s listed in this post assume you have a firewall product in front of the Consolidated Edge server that is performing both resverse proxy and NAT features.

1. External A/V Conferencing – Errors

When testing multiparty A/V conferences I experienced the following errors. These errors were produced when adding a third participant to an existing two party (peer to peer) A/V conference.

Cannot perform the selected action. This action may not be permitted by the conferencing service. Please try again. If the problem persists, please contact your system administrator.

The call was disconnected because you stopped receiving audio from [email protected]. Please try the call again.

An error occurred while trying to take the call off hold. If the problem persists, contact your system administrator. More details (ID:500)

An error occurred while trying to start the conference. More details (ID:52031)

As you can see, there is not a single persistent error that is produced which unfortunately makes troubleshooting slightly more difficult. After spending some time performing SIPStack traces and reviewing Communicator logs via the Snooper Tool, I narrowed the errors down to a firewall and consolidated edge server configuration issue.

2. External A/V Conferencing – Resolution Items

The item’s listed below resolved the external A/V conferencing issues I was experiencing. These steps are also included in the official Microsoft production documentation for Consolidated Edge server deployments.

A/V Edge Service Name Resolution– Configure the Edge Server to resolve the FQDN associated with public A/V Edge service to the publicly routable IP Address, not it’s internal NAT’d IP address. For example, if your A/V Edge service has a public IP address of and a NAT’d IP address of, if you run a command prompt from the Edge Server and type ping av.externaldomain.co.uk it must return A good way of achieving this is making a hosts file entry on your Edge Server to force the FQDN to resolve to the public IP address.

A/V Edge Service NAT– Assuming you have a firewall product (ISA/TMG) in front of your Consolidated Edge server that is performing NAT, configure the A/V Edge service to support NAT by checking the “External IP address is translated by NAT” checkbox. This setting can be found under the Edge Servers properties dialog box.

Firewall Access Rules– Configure your firewall product with the following protocol definitions to allow A/V traffic to be passed to your Consolidated Edge server. Once you have performed this, create a new server publishing rule that targets your Consolidate Edge server and utilises the protocols you have just created.  Please note the below protocol definitions target ISA/Forefront TMG deployments specifically. A very useful article on performing this can be found here.

Protocol nameAV TCP In
Protocol typeTCP
Port Range50000-59999
Protocol nameAV UDP in
Protocol typeUDP
Port Range3478, 50000-59999

Testing Access – If you are using internal clients to perform multiparty A/V testing then ensure those clients have unrestricted access through your internal firewall. I experienced an issue where outbound traffic from my test clients was being blocked by my internal firewall, which in turn created additional issues. Ensure you have complete outbound access for your test clients and then scale back access from there.

I hope this assists your external A/V conferencing implementation.

ISA Server 2006 – Missing RRAS Ports

After recently rebooting a Microsoft ISA 2006 server, I found myself in the situation of being unable to establish VPN connectivity to it from a remote location. After performing several troubleshooting methods, I identified that there were no available PPTP RAS ports listed in the Routing and Remote Access (RRAS) console.

This explained why VPN connections could not be established, however I could see that a pool of ten ports had been configured but for some reason were not available. Some research on this issue led me to identify this was the result of a recent Windows Update. If you have applied KB 956570 to your ISA Server and then rebooted it, you may find yourself in the same situation. To resolve this issue, perform the following actions on the affected server:

1. Click Start and select Run

2. In the Run dialog box enter the following registry command to reset the servers reserved port threshold. Please note, enter this command without the quotation marks:

“reg add HKLM\SYSTEM\CurrentControlSet\Services\Fweng\Parameters /v ReservedPortThreshold /t REG_DWORD /d 1250 /f”

3. To uninstall the update, please run the following script which has been provided by Microsoft for this purpose. I have collated this script, which can be downloaded here for your convenience.

4. Create a new folder on the C: drive of your ISA Server named KBFix and copy the downloaded script (KB956570.vbs) to this folder location.

5. Open the command prompt and browse to the new folder you have just created. This can be achieved by typing cd c:\kbfix and then pressing return on your keyboard.

6. Once in the correct directory type cscript KB956570.vbs and then press return on your keyboard. This will now start the process of removing the update.

7. Once the removal process is complete, reboot your ISA Server and VPN connectivity will be restored.

For reference, here is the official Microsoft TechNet KB article on the problem: http://support.microsoft.com/kb/956570