cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
Announcements

Community Helping Community

461
Views
0
Helpful
5
Replies
Highlighted
Contributor

CUCM and CUC configuration using inter-cluster trunk.

Hi folks,

 

I have CUCM 11.5 on Cluster A and CUC 8.0.3 on Cluster B.

Cluster-A: CUCM & UCCX 11.x.

Cluster-B: CUCM and CUC 8.x.

 

I'm having UCCX 11.6 contact center environment. I've inter-cluster trunk UP and running between CUCM cluster-A and CUCM cluster-B. I have dialled from CIPC and ICTG works smoothly.

 

Problem:

I'm trying to find a solution, during unavailability of users in CUCM cluster-A, call should go to voicemail i.e. CUC on cluster B.

 

thanks & regards,

Ritesh Desai.

Everyone's tags (6)
5 REPLIES 5
Beginner

Re: CUCM and CUC configuration using inter-cluster trunk.

This is from the SRND. It is referring to Sesion management edition but can be used in this case as well.

 

Centralized Voice Mail – Unity Connection

Voicemail applications such as Cisco Unity Connection can be connected to the SME cluster and provide voicemail service to users on all leaf UC systems.

On the intercluster trunks between leaf clusters and SME, and on the trunk connections to the voicemail application, ensure that the original called party or redirecting number is sent with calls routed to voicemail.

For non-QSIG-enabled trunks, the original called party or redirecting number transport can be enabled by:

  • Enabling inbound and outbound Redirecting Number IE Delivery on MGCP gateways, H.323 gateways, and H.323 trunks
  • Enabling inbound and outbound Redirecting Diversion Header Delivery on SIP trunks

For QSIG-enabled SIP, MGCP, and H323 trunks, the original called party number is sent in QSIG Diverting Leg Information APDUs. The diversion information sent in QSIG APDUs over QSIG-enabled trunks does not pick up any calling party modifications and also does not honor the Voice Mail Box Mask setting. QSIG diversion information sent by Unified CM is always set to the redirecting DN without applying any transformations.

If the redirecting DN is configured as +E.164, the leading "+" is removed and the QSIG diversion information carries only the E.164 number without the "+" character.

Considerations for all QSIG Trunk Types

Using QSIG in UC networks today provides a limited number of feature benefits and generally is not recommended. The primary reason for using QSIG is to provide the Call Back feature. (As an alternative, Collaboration users can track another user's state by using presence information provided by the Cisco IM and Presence service.) If you do enable QSIG on trunks from leaf UC systems to SME, you should also enable QSIG on all intercluster trunks; this avoids a poor end user experience where a phone user finds that Call Back works for some (QSIG enabled) called users but not others.

On H.323, MGCP, and SIP trunks with QSIG tunneling enabled, all number information (including calling, called, and redirecting number information) is always taken from the encapsulated QSIG message and not from the outer H.323 message or SIP headers. This QSIG trunk operation can require specialized design considerations for a voicemail system centralized on SME and serving multiple leaf systems.

As a general recommendation, to enable a smooth end-to-end QSIG implementation, a uniform globally unique dial plan should be implemented across all UC systems.

If QSIG trunks are used, redirecting numbers cannot be normalized before they are sent to the centralized voicemail system. This limitation requires that the centralized voicemail system mailbox number for users in each leaf UC system should correspond to the number format of the directory numbers used in each leaf system. For example:

  • Users with directory numbers in E.164 format should have a corresponding voicemail system mailbox number using the same E.164 format.
  • Users with directory numbers in +E164 format should have a corresponding voicemail system mailbox number using the same E164 format and an alternate voice mailbox number using the +E.164 format.
Regards,
Steve
Please rate all helpful posts.
VIP Mentor

Re: CUCM and CUC configuration using inter-cluster trunk.

Why dont you just add the second CUCM cluster to CUC as a new telephony system?

Please rate all useful posts
Beginner

Re: CUCM and CUC configuration using inter-cluster trunk.

one reason you might not want to do that is that you would have to determine how many licensed ports you want to allocate to each cluster.

 

using centralization all ports are available to both clusters.

Regards,
Steve
Please rate all helpful posts.
VIP Mentor

Re: CUCM and CUC configuration using inter-cluster trunk.

Agreed. You will have to allocate port to each telephony system you configure. In my opinion unless you have a SME solution it is a much cleaner solution.

Please rate all useful posts
Beginner

Re: CUCM and CUC configuration using inter-cluster trunk.

I prefer centralized but I agree that connections to each is cleaner.... especially if you don't have the experience to support/troubleshoot issues that having multiple clusters creates.

 

 

Regards,
Steve
Please rate all helpful posts.
CreatePlease to create content
Content for Community-Ad
FusionCharts will render here