Home > Lync > Avaya RCC Integration with OCS 2007 R2

Avaya RCC Integration with OCS 2007 R2

Over the past month I have been dealing with an issue at a client that neither Microsoft nor Avaya has been able to resolve. This issue was a simple Enterprise Voice + PBX integration between Microsoft Office Communications Server 2007 R2 and Avaya AES 4.2/Avaya SES.

Our configuration consisted of an Enterprise Pool with a single Front End server, two consolidated edge servers and two mediation servers. The connection from SES to the OCS Mediation server went without a hitch and calls instantly were working between the two systems.

Our PKI infrastructure consisted of a Windows Server 2003 R2 Standard edition enterprise root CA which does not have the ability to create custom certificate templates required for integration with AES. The custom certificate template is simply a copy of the web server template with the addition of client authentication to the “Application Policies Extension” (see page 15 of OCS-ACM-RCC.pdf). So we added an enterprise subordinate CA running Windows Server 2008 Enterprise Edition, created the certificate template and issued a cert following the guidelines in the Avaya Integration Doc. One thing they don’t mention in the Integration Document is how you get a certificate with from that template on the OCS Front End Server. The OCS wizard assumes you are using the “Web Server” template and issues a request to your CA with that template specified and you cannot specify a different template in the wizard. To issue a certificate with the new template you must manually generate the certificate request outside the OCS wizard and submit the request through the certsrv website (that is another post altogether)

The next effort was to get RCC working with AES and actually to take it a step further and get EV+PBX integration working. Logging on the MOC client and OCS servers showed the TLS connection to the Avaya AES server was built and functioning properly. Sessions were showing on the AES server with the MOC but were immediately torn down.

We had a feeling from the beginning that this was a TLS issue, simply because we were not able to “establish chain of trust” when importing the certificate to the AES server. Whatever you read in the forums or blogs, this checkbox must remain CHECKED! If you are not able to establish the chain of trust, there is a problem. Our problem was the OU field in the certificate request and certificate. Typically, the OU field is not required or is populated with a descriptive location for the server (ie: servers). Simply leaving out the OU= in the certificate request and subsequent certificate allowed us to establish chain of trust and RCC/EV+PBX integration started working immediately.

I have included some helpful troubleshooting tips and screenshots to show how this should be configured as evidenced by a functional system.

Troubleshooting steps:

Make sure all TR/87 tests to pass on the AES server but don’t stop here! This has nothing to do with OCS at this point.

Ensure the certificate you imported had “establish chain of trust” checked. It is not good enough for the certificate to say “valid”. If you are not able to establish the chain of trust the certificate will not work.

The host name of the AES server should be configured with the FQDN you have configured in the host authorization and routing tab on your enterprise pool front end properties.

Make sure you can telnet to port 4723 on the AES server

If you get an error on your MOC with “No Phone System Integration” make sure you set the port on the static route is set to 4723 not the default of 5061.

The static route domain and FQDN as shown should equal the FQDN of the Avaya AES server, the transport type is TLS and port is 4723.

Two entries should be created for each AES server, one for the IP address and another for the FQDN as shown.

Users should be configured with either EV+PBX Integration or RCC. The Server URI should be configured to be sip:aes@FQDN of AES server.

Categories: Lync
  1. June 9, 2012 at 7:30 am

    Kevin was able to help me sort all of my issues out, thank you so much Kevin. He went above and benoyd by totally working through all of my issues. The problem came down to the subject in the certificate not matching what I put in the host authorization section of OCS. I purchased a multidomain certificate, well the first subject name was something other than the OWA FQDN, previously I only had the OWA FQDN in the Host Authorization section, once we placed the correct subject name in the Host Authorization section we had to stop all running services and then start all running services.

  1. No trackbacks yet.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: