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.
