Integration between CUPS and MOC/OCS

For now, to integrate MOC (Microsoft Office Communicator) with Cisco IP phone system (CUCM) you need CUPS for phone presence and phone control.

Phone presence

Phone presence info will flow like this: CUCM -> CUPS -> OCS -> MOC.

Phone control

Phone control info will flow like this: MOC -> OCS -> CUPS -> CUCM.

Best Practices

Use TCP instead of TLS on your first deployment. TLS/Cetificates are not something fun to play with. They are optional for the integration. Per the KISS (Keep It Simple, Stupid) principle, don't mess with TLS unless you have to.

Let's talk about phone control first. Currently, Cisco support RCC (Remote Call Control) for MOC.

RCC was configured in Active Directory Users and Computers (ADUC) > Communications.


As you can see from the picture above, we need to configure Server URI and Line URI.

6002 is the IP phone DN (Directory Number).

htluo-cups is the proxy domain that will process the request. We'll further discuss this part later.

When MOC starts up, it'll send "INVITE 6002@htluo-cups6" to OCS.

When OCS receives the INVITE message, it'll try to route it to the right destination (CUPS in this case).

How OCS routes the message is more complicated than it looks like. It could be static route, it could be DNS lookup. For more details see "SIP domain and DNS domain".

Again, per KISS principle, it's recommended to use static route on OCS to eliminate any misconfiguration of DNS.


As shown above, the static route means "for any SIP message with domain htluo-cups6, forward it to 10.88.229.209, port 5060, with TCP protocol".

In order for CUPS to accept this message, OCS' IP address must be added to CUPS Incoming ACL. (or you may configure an "ALL" incoming ACL)

When CUPS server receives the message from OCS, the first thing it does is to determine if message has reached the final destination. CUPS compares its own configuration with the domain portion of the SIP message. If the domain portion of the SIP message matches one of the following, CUPS would think the message arrives at its final destination and take care of that.

a) SIP domain name (configured under CUPS Admin > System > Service Parameters)
b) CUPS node name (configured under CUPS Admin > System > Server)
c) node name + SIP domain
d) other alias name configured on CUPS

To see a full list of alias names, set "SIP Proxy" trace to detail. Restart SIP Proxy service. SIP Proxy would write a list of alias names to trace files during startup.

If CUPS decided to take care of the INVITE message from OCS, it will do the following:

1) Determine if the MOC user has permission to control the phone
2) If step 1 was ok, open a CTI request to CUCM CTIManager
3) If step 2 was successful, return "200 OK" SIP message to OCS

Determine if the MOC user has permission to control the phone

In the Server URI (tel:6002;phone-context=dialstring;device=SEP001E7A24429A), if a device name was specified (which was in this case), CUPS will check if that device was in the "Controlled Devices" list on CUCM Admin > User Management > End User.

If no device name was specified in Server URI, CUPS will try to find the device by DN. For details, please see: http://www.cisco.com/en/US/docs/voice_ip_comm/cups/6_0_1/install_upgrade/deployment/guide/dgmsint.html#wp1049685

Again, per KISS principle, you'd better specify device name in Server URI on your first deployment.

Open a CTI request to CUCM CTIManager

CUPS will open a CTI request to CUCM CTIManager with the credential configured on CUPS Admin > Application > CTI Gateway > Settings (CUPS 6.x).

Of course, the credential needs to exsit on CUCM > User Management > Application User. It needs to be in "Standard CTI Enabled" and "Standard CTI Allow Control of All Devices" groups.

And of course, the phone device needs to be registered to CUCM.

If all above was successful, CUPS will send "200 OK" to OCS as an response to the INVITE.

At this point, CUPS has done its job. But it does not necessarily mean MOC gets phone control.

In order for OCS to accept the "200 OK" message from CUPS, CUPS' IP address must be added to OCS "Host Authorization" (please note, it's IP address, not hostname or FQDN).


Don't forget to restart OCS Front End services after making changes.

The best tool to debug OCS/CUPS integration is on OCS. Right-click on the pool > Logging Tool > New Debug Session. Choose SIP Stack. Optionally, you may filter by the MOC user ID in the filter settings.

Known caveats:

1. CUPS sent "200 OK" for the INVITE. But MOC still not getting phone control.

This is because OCS doesn't trust CUPS. OCS SIP stack log will show "SIPPROXY_E_INVALID_RECORD_ROUTE"

Resolution: Check "Host Authorization" on OCS.

2. Load balancer

If you have load balancer for OCS, more likely than not, you will run into "one-way phone control" issue. The symptom is: you can make phone calls from MOC. But the call status was not updated on MOC. For example, when the call was connected, MOC still showing "calling".

This problem was caused by misconfiguration of load-balancing.

When OCS sends message to CUPS, it doesn't go through load-balancer (based on your exsiting configuration).

When CUPS tries to reply to OCS, it looks up DNS and DNS resolve the pool name to the load-balancer virtual IP. So the traffic goes through load-balancer to get to OCS. When OCS received the message, the last hop was load-balancer. However, the load-balancer didn't add its IP to the SIP header. OCS will reject this message and send "400 Missing correct Via header" to CUPS.

Resolution:
Check your load-balancer, see if it's capable of modifying SIP header. Or contact Microsoft to see if they can turn off the "Via header" check on OCS.