CUC Cluster SIP Integration with CUCM Cluster

[Ahmed habib]

Hello,

I want to ask why in CUC SIP Integration with CUCM, We create 2 SIP Trunks for CUC PUB & SUB and RG rather than putting CUC SUB IP in the second field in destination address in SIP Trunk as we do with IM & P

Can anyone illustrate this point technically

[Roger Kallberg]

The primary reason is to be able to control the preferences between the SIP trunks. With CUC design guide recommendation is to use the subscriber as the preferred receiver with the publisher as the second option. This can be controlled with route list/route group setup. Whereas if you put both IPs/FQDNs in one trunk the system would round robin between the two with no option to control the preferred. I hope this helps.

[Ahmed habib]

Thanks for your answer, Can you share this point in the Guide to know the wise.

And why this not happen in IM&P for Example. I need more clarification if possible

[Roger Kallberg]

It’s covered in the integration guide. https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/connection/11x/integration/guide/cucm_sip/b_cucintcucmsip.html

For IM&P it doesn’t matter what node the communication goes via. That’s why it is okay to use one trunk with multiple destinations.

[Ahmed habib]

I am still confused why it does matter with CUC to create separate trunks in communication ?

[Ayodeji Okanlawon · Accepted solution]

Ahmed, @Roger Kallberg  has already given you the answer. Let me break it down a little.

CUCM sends calls to IP addresses defined in a sip trunk randomly. This means that you cannot influence where calls go as this is all done by cucm. 

This is not good for CUC. Why? Because you do not want your publisher to be processing calls when your subscriber is operational. If you don't define seperate trunks and influence their order using route groups, then your publisher will also be receiving calls as I explained earlier.

In Summary the main reason you do this is to ensure that calls are not going to your cuc publisher when your subscriber is up and running

[Ahmed habib]

Thank you @Ayodeji Okanlawon  for Explanation

but Why this (In Summary the main reason you do this is to ensure that calls are not going to your cuc publisher when your subscriber is up and running) even my Pub is primary and SUB is secondary as attached

and RG is

Current Route Group Members
Selected Devices (ordered by priority)Required Field

CUC-PUB_Trunk (All Ports)

CUC-SUB_Trunk (All Ports)

[Roger Kallberg · Accepted solution]

It’s just the way Unity Connection is designed. Who has the primary role is not related to this specifics. You should change the order of the trunks in your route group to follow the design recommendation.

If you really want to have even more details around this specific topic this forum isn’t the place for you. You’d need to reach out to Cisco and have a discussion with the BU to get the “Why is this designed this way?” answered.