SIP Trunk CSS to CUC 10.5

[ian-lewis]

Guys

Forgive me if this is an obvious question.

I am working on a site where they have multiple offices and are adding more all the time.

When I went to add the Phone Partition into the CSS for the SIP Trunk to CUC, I get the Number of Characters Exceeded issue.  I started to set up a new trunk, but then I see they already have two trunks, one to the CUC Pub and one to the CUC Sub, on port 5060.

Can I just pick a new port to create the trunk to CUC on?  If so, where would I allow that on CUC, it's not something I've had to do before.

As the plan is to add multiple offices onto this cluster, I really need to sort this out for going forwards.

Thanks, in advance, for any advise

Ian

[Mohamed Amine Jaafar]

I don't think this would be a good workaround since the design of the solution is to integrate the CUCM cluster to CUC Cluster, and not to CUC nodes independently.

Your best bet is to concentrate on optimizing the Partitions and CSSs.

Otherwise, I suggest to split the CSS and route incoming calls via translation patterns.

For this you create two partitions : PT_TP_Pool1 and PT_TP_Pool2 and put both in a new CSS called CSS_VoiceMail_IN. Create two translations patterns one with "[0-4]!" in Partition PT_TP_Pool1 which will translate the CSS to CSS_Pool1_Phones (you create it) and a second with "[5-9]!".in Partition PT_TP_Pool2 which translate CSS to CSS_Pool2_Phones (you create it too). Then apply the CSS_VoiceMail_IN to the Unity Connection SIP Trunk. (the "[0-4]!" and "[5-9]!" are just a suggestion, you may change the way to split patterns in order to equally share your dial-plan and thus CSSs)

This should solve your issue at least for now. But you should really consider optimizing your Partitions and clean up the configuration.

[ian-lewis]

This is for a cluster designed to hold 70 k users across multiple sites.  The previous naming convention has part of the address, with different suffix's, to control where calls can be routed.  There are, potentially, 1500 offices in EMEA alone they are also working with E164 dial-plan, so I think this will be a major exercise to optimize them :-(

Thanks, I'll let you know how I get on

Ian