However, CUPS and CUPC are more like peers. They were designed by two different groups of developers. These two groups treat each other as an "important customer", but not the only customer.
For example, CUPS can be used without CUPC.
Example #1: MOC RCC (Microsoft Office Communicator Remote Call Control).
MOC can control an IP Phone via CUPS and CUCM without CUPC in the picture.
Example #2: SIP Proxy
CUPS acts as a SIP proxy without CUPC in the picture.
Example #3: IPPM (IP Phone Messenger)
An IP phone can see buddy's status, send IMs, retrieve meeting schedules without CUPC in the picture.
On the other hand, CUPC was built as a multi-function software other than just a "CUPS client".
Right now, CUPC can't function without CUPS. Because it uses CUPS as a configuration repository. CUPC has to retrieve the configuration from CUPS for all its features. But except for the presence feature, all other features do NOT rely on CUPS.
For example, CUPC's soft phone feature is most demanded from Mac OS users. It's the only Cisco soft phone works on Mac OS. (CIPC - Cisco IP Communicator does not run on Mac). However, to use CUPC, you need a CUPS server. In this scenario, CUPS server provides no value other than supplying the TFTP address to CUPC. If CUPC can save the TFTP address locally (like CIPC), there's no need for CUPS server. It makes perfect sense from both technical and economic perspective.
Same for other CUPC features like Voicemail, Web Conference, LDAP search, click to dial, etc.
For this reason, CUPC developers are considering the options of "separating CUPC from CUPS" and make them more independent to each other.
With that said, CUPC and CUPS are more like peers other than father and son (or couple). Keep that in mind would help you understanding the function modules of CUPC.