Troubleshooting Convergence in MOC

Forgive the multiple postings, Dennis kindly alerted me that the images were not displaying. As I was doing this with a VPN to our corporate network the images displayed as I could connect to the source location.

Jason Epperly has given permission to repost his internal blog on the subject.

So, I get this case where the error icon at the bottom of Microsoft Office Communicator (MOC). Looks like this:

So up to this point I have not had to figure out what this error icon really indicates. Using my deductive prowess I clicked it and…

So based on this, this error is what happens when the MOC client is in a state that it cannot control the hardphone sitting next my computer. This begs the question, how does MOC establish the connection to the hardphone in order to "control" it.

So in the Active Directory the user has an attribute for the Remote Call Control (RCC) SIP URI. You configure this using ADU&C or from the LCS MMC. The dialog looks like this:

When MOC starts up, (just after the authentication completes), the client sends a SUBSCRIBE for provisioning data. This data includes the SIP URI listed above (the one labeled Remote Call Control SIP URI). The client now knows where to send remote call control command to, but before the client can send the control commands the client must establish a session to this endpoint. In this case the customer was integrating LCS with a Nortel solution that included a LCS application proxy (which ran their MCM (Multimedia Convergence Manager) application), a Nortel NRS (Network Redirect Server), and a Nortel CS 1000 (Communication Server). The control channel between the client and the RCC user agent is setup using the following SIP flow:

This flow came from the Nortel docs which were quite good. Now that I had a "known good" we went back to the customer's configuration of the Home Server and the Application Proxy. Turns out they did not have all the routing rules they needed to allow the configuration above to work. On the Home Server side they need a routing rule for the RCC User Agent so the sip invite will be forwarded to the Application Proxy, and on the Application Proxy they needed a routing rule routed any (*.*) user agent back to the Home Server.