Networking Guide for Cisco Unity Connection Release 10.x

About Linking Two Unity Connection Sites

When you link two Unity Connection sites with an intersite link, the gateway for each site is responsible for collecting information about all changes to the local site directory, and for polling the remote site gateway periodically to obtain information about updates to the remote site directory. The gateways use the HTTP or HTTPS protocol to exchange directory synchronization updates.

Each site gateway is also responsible for transmitting messages that are addressed to recipients at the remote site and for receiving messages that are addressed to recipients in its own site. Intersite messages are transmitted and received using SMTP.

When you use a Unity Connection cluster as a site gateway, only the publisher server in the cluster participates in directory synchronization over the intersite link. However, the subscriber server continues to provide message exchange over the intersite link if the publisher server is down.

Figure 1-2 illustrates the role of the site gateways and the intersite link in connecting two Unity Connection sites.

Note In order to link two Unity Connection sites, all servers in each site must be running Unity Connection version10.x.

Figure 1-2 A Cisco Voicemail Organization Consisting of Two Unity Connection Sites Connected through an Intersite Link

About Linking Unity Connection and Cisco Unity Sites

When you link a Cisco Unity site to a Unity Connection site, the gateway for each site is responsible for collecting information about all changes to the local site directory, and for polling the remote site gateway periodically to obtain information about updates to the remote site directory. The gateways use the HTTP or HTTPS protocol to exchange directory synchronization updates.

For message exchange, the Interoperability Gateway for Microsoft Exchange functions as the messaging gateway for the Cisco Unity site. The Interoperability Gateway can be installed on a Microsoft Exchange 2010 or Exchange 2007 server configured with the Hub Transport role, or on a Microsoft Exchange 2003 server. (For up-to-date version support and requirements for the Interoperability Gateway, see the Cisco Unity Networking Options Requirements at http://www.cisco.com/en/US/docs/voice_ip_comm/unity/compatibility/matrix/cunetoptionsreqs.html.)

Messages composed by Cisco Unity users that include external recipients are routed by the mail system to a folder that the Interoperability Gateway periodically checks. The Interoperability Gateway picks up a message to be processed from the folder, looks up and translates the sender and recipient information into the required format, adds or removes message properties as applicable, converts and encrypts or decrypts the audio if applicable for the destination location, performs message part and format conversion, and hands the message back to the messaging system for delivery. For several of these tasks, the Interoperability Gateway needs access to Cisco Unity directory information. To get this information, it contacts the Cisco Unity web services resource on a Cisco Unity 8.x server in the Cisco Unity site. (The Interoperability Gateway can be configured to use both a primary and secondary web services server. The site gateway can be used as the web services server, although any 8.x server in the site can be used.)

Figure 1-3 depicts—at a high level—the role of the Interoperability Gateway for Microsoft Exchange, the site gateways, and the intersite link in connecting Cisco Unity and Cisco Unity Connection sites. The Cisco Unity site can consist of a single Cisco Unity server, a failover pair, or a Digital Network containing multiple Cisco Unity servers or failover pairs. Likewise, the Unity Connection site can consist of a single Unity Connection server, a Unity Connection cluster, or more than one server or cluster.

Figure 1-3 Cisco Voicemail Organization Consisting of a Cisco Unity Site Connected to a Unity Connection Site via an Intersite Link

Note that in order to link Cisco Unity and Unity Connection sites, all servers in the Unity Connection site must be running Unity Connection 10.x. The Cisco Unity site gateway must be running Cisco Unity 8.x. Other Cisco Unity servers in the Cisco Unity site may be running Cisco Unity 5.0 and later with Microsoft Exchange provided that the applicable engineering special is installed to add Unity Connection Networking support. For additional details and requirements, see the Cisco Unity Networking Options Requirements at http://www.cisco.com/en/US/docs/voice_ip_comm/unity/compatibility/matrix/cunetoptionsreqs.html.)

When you use a Unity Connection cluster as the Unity Connection site gateway, only the publisher server in the cluster participates in directory synchronization with Cisco Unity. However, the subscriber server can continue to provide message exchange over the intersite link if the publisher server is down. Likewise, when you use a Cisco Unity failover pair as the Cisco Unity site gateway, only the primary Cisco Unity server participates in directory synchronization with Unity Connection, although message exchange can continue even when the secondary Cisco Unity server is active.

Replication Within a Unity Connection Site

Within a Unity Connection site, each location replicates the objects and object properties shown in Table 1-1 from its directory to every other location:

In most cases, you can use replicated objects just as you would use local objects; for example, you can assign a remote user to be the message recipient of a system call handler, or configure the search scope of a user to use a remote search space. Note the following exceptions:

• System call handler owners must be local users.
• Objects that belong to a partition (users, contacts, handlers, system distribution lists, and VPIM locations) can only belong to local partitions. You can, however, add a remote partition to a local search space.

When a replicated object that is homed on a Unity Connection location is added, modified or deleted, the location sends an object change request containing details about the change to all other locations. The object change requests for a given location are ordered and tracked with a number known as the Unique Sequence Number (USN). For each change, the location increments the USN by one, and notes the change in its database. When a remote location receives an object change request with a USN value that is one higher than the previous request it received from the sender, it updates its copy of the Unity Connection directory accordingly, and increments its tracked copy of the USN for the sender. If a remote location misses one or more changes and receives a change request with a USN that is more than one higher than the previous request it received from this location, it can retrieve the missed changes by requesting the USN values that it missed.

In addition to the USN, each location has another associated number known as the Replication Set. The Replication Set value is used to track the set of changes to which a USN belongs. The Replication Set value is automatically changed during an upgrade, restore, or rollback operation. This ensures that any changes to the database as a result of the operation are replicated to the network. For example, if Location A receives a message with replication set 10 and USN 5 from Location B, and then receives a message with replication set 9and USN 5 from Location B, it knows to ignore the message with replication set 9 because it is a lower number and the message predates the message with replication set 10. If Location A receives another message from Location B with replication set 10 and USN 5 again, Location A knows this is a duplicate message and can ignore it.

When a bulk operation is in progress on a location, replication is paused on that location until the operation completes.

Replication Between Two Unity Connection Sites

As shown in Table 1-2 , the same objects and object properties are replicated between two Unity Connection sites as within a single Unity Connection site, with the following exceptions:

• System contacts are not replicated between sites.
• For each site, you can select whether to synchronize all system distribution lists that are homed on the remote site. Also, for each individual list, you can select whether the list is offered for replication to the remote site.
• System distribution list membership is not replicated between sites.
• VPIM locations (and contacts) are not replicated between sites.

Just as with intrasite links, you can use replicated objects from a remote site just as you would use local objects, except that call handler owners must be local users, and objects that belong to a partition can only belong to local partitions.

Intersite replication is accomplished by means of a Feeder service and a Reader service running on each site gateway. The Reader service periodically polls the remote site gateway for any directory changes since the last poll interval. The Feeder service checks the change tracking database for directory changes and responds to poll requests with the necessary information.

On each site gateway, you can configure the schedule on which the Reader polls the remote Feeder for directory data, and the schedule on which it polls for recorded names. In Cisco Unity Connection Administration on a site gateway, you can access the schedules on the Tools > Task Management page selecting either the Synchronize Directory With Remote Network task or the Synchronize Voice Names With Remote Network task. Alternatively, you can access either task using the Related Links field on the Edit Intersite Link page.

When the Synchronize Voice Names With Remote Network task is enabled, the reader process recorded name files for remote users and system distribution lists (if applicable). Once a recorded name is created for a remote object on the local site, it is updated only if the remote and local filenames for the recorded name differ. If, for example, you change the outgoing codec for recorded names on the remote site gateway, the local site does not update its files because the change does not affect filenames. In order to pull updated copies of recorded names in this case, you must clear all existing recorded names from the local site gateway and then do a full resynchronization using the Clear Recorded Names button and the Resync All button on the Search Intersite Links page in Unity Connection Administration.

Replication Between Cisco Unity and Unity Connection Sites

When you link a Cisco Unity site and a Unity Connection site, a contact (known as a Unity Connection Networking subscriber in the Cisco Unity Administrator) is added to the Cisco Unity directory and to Active Directory for each Unity Connection user. Likewise, a user (known as a Cisco Unity user in Cisco Unity Connection Administration) is added to the Unity Connection site global directory for each Cisco Unity user. Unity Connection system contacts and VPIM contacts are not replicated to Cisco Unity, nor are Cisco Unity networking contacts (AMIS, Bridge, VPIM, Internet, or Trusted Internet subscribers) replicated to Unity Connection.

A system distribution list may be replicated from one site to another if the local site is configured to pull lists from the remote site, and if the list itself is configured to allow replication to other sites. Lists that contain system contacts or networking contacts cannot be configured to allow replication to other sites. For those lists that are replicated, only the list name and other information used in addressing are replicated; list membership is not replicated.

Table 1-3 lists the objects that are replicated between Cisco Unity and Unity Connection sites, and the object properties that are replicated.

Intersite replication is accomplished by means of a Feeder service and a Reader service running on each site gateway. The Reader service periodically polls the remote site gateway for any directory changes since the last poll interval. The Feeder service checks the change tracking database for directory changes and responds to poll requests with the necessary information.

On the Unity Connection site gateway, you can configure the schedule on which the Reader polls the remote Feeder for directory data, and the schedule on which it polls for recorded names. In Cisco Unity Connection Administration on a site gateway, you can access the schedules on the Tools > Task Management page selecting either the Synchronize Directory With Remote Network task or the Synchronize Voice Names With Remote Network task. Alternatively, you can access either task using the Related Links field on the Edit Intersite Link page.

On the Cisco Unity site gateway, you can enable or disable synchronization of recorded names, and configure the interval at which the Reader polls the Unity Connection Feeder for directory updates and recorded names. Note that unlike the Unity Connection Reader, which has separate configurable schedules for polling directory data and recorded names, the Cisco Unity Reader polls for both (if recorded name synchronization is enabled) during each cycle.

When the Synchronize Voice Names With Remote Network task is enabled, the Reader processes the recorded name files for remote users and system distribution lists (if applicable). When a recorded name has been created for a remote object on the local site, it is updated only if the remote and local filenames for the recorded name differ. If, for example, you change the outgoing codec for recorded names on the remote site gateway, the local site does not update its files because the change does not affect filenames. In order to pull updated copies of recorded names from Cisco Unity to Unity Connection, you must clear all existing recorded names from the Unity Connection site gateway using the Clear Recorded Names button on the Networking > Links > Search Intersite Links page in Unity Connection Administration. In order to pull updated copies of recorded names from Unity Connection to Cisco Unity, use the Clear Voice Names button on the Network > Unity Connection Networking Profile page in the Cisco Unity Administrator.

How Messages to System Distribution Lists are Handled Within a Unity Connection Site

Because system distribution lists are replicated among locations in a Unity Connection site, a user can address messages to any system distribution list at any location, as long as the list is reachable in the user search scope.

When a user addresses a message to a system distribution list, the local Unity Connection location parses the distribution list membership. The sending location delivers the message directly to local users on the list. If there are remote Unity Connection users on the list, the sending location delivers the message to each location that homes these remote users. If there are VPIM users on the list, the sending server either delivers the message to the VPIM destination if the VPIM location is homed locally, or passes it to the server on which the location is homed and that server handles forwarding the message to the destination server.

Unity Connection includes the following predefined system distribution lists: All Voicemail Users, Undeliverable Messages, and All Voicemail-Enabled Contacts. Each Unity Connection server in your organization has a distinct version of each of these lists. If you have not changed the names of these lists to be unique, during initial replication each server automatically adds the remote server name to the display name of any remote lists whose names overlap with local list names.

By default, the predefined lists on each Unity Connection location have the same recorded name, and the All Voicemail Users and All Voicemail-Enabled Contacts lists have the same extension at each location (the Undeliverable Messages list by default is not assigned an extension, because users do not typically address messages to this list). When setting up a Unity Connection site, you should consider modifying the recorded name of each All Voicemail Users list and each All Voicemail-Enabled Contacts list; if you do not, users can hear a confusing list of choices when they address messages by name to one of these lists. When users address by extension to a list whose extension overlaps that of another list, they reach the first list that is located when Unity Connection searches the partitions of the user search space in order.

Tip Distribution lists can be nested such that a distribution list contains other lists. You can create one master All Voicemail Users distribution list for a site that contains the All Voicemail Users list of each Unity Connection location.

How Messages to System Distribution Lists are Handled Between Sites

With intersite networking (either between Unity Connection sites or between Cisco Unity and Unity Connection sites), replication of system distribution lists is optional, and when lists are replicated, only the information needed to address a message to the list is replicated. Therefore, when a user addresses a message to a system distribution list that is homed in another site, the message is routed to the remote site gateway (if the remote site is a Unity Connection site) or to the Interoperability Gateway for Microsoft Exchange (if the remote site is a Cisco Unity site). At this point, the system distribution list recipient is handled as though the message originated within the remote site.

It is possible to nest system distribution lists such that a local list contains remote lists as members. For example, you could nest the All Voicemail Users distribution list from one site within the All Voicemail Users list of the other site. (If you are networking Cisco Unity with Unity Connection, note that Unity Connection users may be automatically created as members of the All Subscribers list or other lists depending on the template that you specify when creating the intersite link.) When you nest a remote list as a member of a local list, you should follow the given practices:

• Avoid nesting local lists as members of the remote list.
• Do not allow the local list to replicate to the remote site.

Addressing Options for Non-Networked Phone Systems

If your organization has a separate phone system for each location, users at one location dial a complete phone number, not just an extension, when calling someone at another location. When users sign in to send messages to users on another networked location, the number that they enter when addressing a message by extension depends on whether the numbering plans overlap across locations.

When user extensions on one location overlap with user extensions on another location, you can provide unique extensions for each user by setting up alternate extensions for each user account. For each user, enter a number for the alternate extension that is the same as the full phone number for the user, and make sure that the alternate extension is in a partition that is a member of the search spaces that users at other locations use. Once this has been set up, when users sign in to send messages, the number that they enter when addressing messages is the same number that they use when calling.

When numbering plans do not overlap across networked locations—that is, when user extensions are unique across locations—users can enter an extension when addressing a message to a user who is associated with another location. Optionally, as a convenience for users in this circumstance, you may select to add alternate extensions to each user account, so that users do not need to remember two different numbers—one for calling a user directly, and one for addressing a message. However, if you do not set up alternate extensions, be sure to tell users to use the extension instead of the full phone number when addressing messages to users who are associated with another location.

Note that alternate extensions have other purposes beyond their use in networking, such as handling multiple line appearances on user phones.

Identified User Messaging

When a user calls another user, and the call is forwarded to the greeting of the called user, the ability of Unity Connection to identify that it is a user who is leaving a message is referred to as identified user messaging. Because Unity Connection is able to identify the caller as a user:

• Unity Connection plays the internal greeting of the called user when the caller leaves a message.
• Unity Connection plays the recorded name of the user who left the message when the recipient listens to the message.
• Unity Connection allows the recipient to record a reply.

It is important to note the difference between the following two circumstances:

• A user signs in to Unity Connection, and then records and sends a message. In this circumstance, when the user has signed in, Unity Connection can identify the message as being from the user, regardless of which location the message recipient is homed on. In this case, the phone system is not involved and the recipient phone does not ring. Instead, the message is sent via networking message exchange (using SMTP).
• A user places a phone call to another user, and then leaves a message. This circumstance is the basis of identified user messaging.

As long as identified user messaging is enabled on a Unity Connection location, Unity Connection is able to identify both local and remote users. Note, however, that for identified user messaging to work in both cases, the initial search scope of the call must be set to a search space that locates the correct user based on the calling extension, regardless of whether the caller is a local or remote user.

If a user calls from an extension that is in a partition that is not a member of the search space that was set as the initial search scope for the call, the call is not identified as coming from the user. If the extension of the user overlaps with an extension in another partition that also appears in this search space, the call is identified as coming from the first object that Unity Connection finds when searching the partitions in the order that they appear in the search space.

In situations where numbering plans overlap across locations, it is therefore possible to have a user leave a message that is incorrectly identified as coming from another user with the same extension in a different partition. Because the initial search scope of the call is based on call routing rules, to avoid this situation, use the following configuration guidelines:

• Maintain a separate search space for each location in which the partition containing its users appears first in the search space. (By default, each Unity Connection server uses its own default partition and default search space, which are replicated to other locations when the server is networked.)
• On each location, set up forwarded call routing rules specific to every other location by specifying a routing rule condition that applies only to calls from that location (for example, based on the port or phone system of the incoming call). Configure the rule to set the search scope of the call to the search space in which the partition containing users at the location appears first.

Considerations for Intersite Networking Between Cisco Unity and Unity Connection

See the following sections:

• Unity Connection Search Spaces and Cisco Unity Users
• Cisco Unity Dialing Domains and Unity Connection Users
• Combining Cisco Unity Unified Messaging and Unity Connection Integrated Messaging When Users Have Accounts in the Same Active Directory Deployment

Unity Connection Search Spaces and Cisco Unity Users

When you link a Cisco Unity site and a Unity Connection site, a partition is automatically created in the Unity Connection directory for each Cisco Unity server, and all Cisco Unity users and system distribution lists that are homed on the server are placed in the partition. However, the partition is not automatically added to search spaces on the Unity Connection locations. In order for Unity Connection users to have permission to address messages to Cisco Unity users, you must add the partition to the search spaces used by those Unity Connection users. Note that the order a partition appears in a search space is important if users address messages by extension. If, for example, Unity Connection and Cisco Unity users have overlapping 4-digit extensions and you want Unity Connection users to be able to reach other Unity Connection users by their 4-digit primary extension and reach Cisco Unity users by a unique 7-digit alternate extension, make sure that the Cisco Unity partition appears after any Unity Connection partitions that contain the overlapping 4-digit extensions.

Cisco Unity Dialing Domains and Unity Connection Users

A dialing domain is a collection of servers that access the same directory and that are integrated with the same phone system or phone system network. A dialing domain is a grouping scheme that allows Cisco Unity to handle call transfers and addressing by extension from one server to another. Within the dialing domain, extensions must be unique just as the phone extensions in the phone system must be unique.

When you link a Cisco Unity site and a Unity Connection site, the Unity Connection user and system distribution list objects that are created in the Cisco Unity directory belong to the dialing domain that is configured on the Cisco Unity site gateway. Because the Unity Connection search space and partition design accommodates overlapping extensions and may include users who have a primary extension and alternate extensions in different partitions, you must select how to map Unity Connection extensions to the Cisco Unity dialing domain. To do so, for each Unity Connection location, you specify a single partition that Cisco Unity pulls extensions from. (In Cisco Unity Connection Administration, you configure the Local Partition That Cisco Unity Users Can Address to By Extension field on the Edit Location page for the local location.) For example, consider a Unity Connection user, Kelly Bader, who has two extensions—a primary extension (4441) in the “Sales Partition” and an alternate extension (2025555) in the “Chicago Partition.” If the partition that maps extensions to the dialing domain for Kelly’s home server location is “Chicago Partition,” Cisco Unity users can address to Kelly by entering extension 2025555; they do not address to her by entering extension 4441. If the partition that maps to the dialing domain for Kelly’s location is changed to “Sales Partition,” Cisco Unity users can address to Kelly by entering extension 4441 but not by entering extension 2025555. (In either case, Cisco Unity users can address to Kelly by name rather than by extension.)

If the extension of a Unity Connection user conflicts with an existing extension in the dialing domain, and the user has alternate extensions available in the partition that Cisco Unity pulls from, Cisco Unity attempts to assign one of the alternate extensions of the user as the extension of the corresponding contact object. If there are no alternate extensions available or if the alternate extensions all conflict with existing extensions in the dialing domain, the new object is created without an extension, and can only be addressed by name. Similarly, if the object does not have any extension in the partition that maps to the dialing domain, the new object is created without an extension.

Combining Cisco Unity Unified Messaging and Unity Connection Integrated Messaging When Users Have Accounts in the Same Active Directory Deployment

When you link a Cisco Unity Unified Messaging site with a Unity Connection site and users in both sites have email accounts in the same Active Directory environment, the contacts that Cisco Unity creates for Unity Connection users can complicate the user experience when users address messages via ViewMail for Outlook or other email clients.

Consider as an example the following two users:

• Pat Jones, a Cisco Unity user with a Unified Messaging account that uses the alias pjones@example.com. Pat uses Microsoft Outlook and Cisco Unity ViewMail for Outlook to access email and voice messages in one mailbox.
• Robin Smith, a Unity Connection user who also has a separate Microsoft Exchange email account with alias rsmith@example.com. Robin uses Microsoft Outlook and Unity Connection ViewMail for Outlook to access email in the Exchange mailbox and voice messages in the Unity Connection mailbox.

Prior to linking the Cisco Unity and Unity Connection sites, the contacts list that Pat and Robin use in Outlook contains one entry for Pat Jones as pjones@example.com and one for Robin Smith as rsmith@example.com. Robin also has rsmith@example.com defined as an SMTP proxy address in Unity Connection in order to send voice messages with Unity Connection ViewMail for Outlook and receive messages that are addressed using the Outlook contacts list. (Before the two sites are linked, however, Pat and Robin cannot use their ViewMail clients to send voice messages to each other).

Once the two sites are linked, Cisco Unity adds an additional contact to Active Directory for Robin Smith. By default, this contact has a display name of “Robin Smith - Voicemail” to distinguish it from Robin’s Exchange account. (The -Voicemail display name suffix is configurable.) The contact has an SMTP address in the format UCI_<alias>_BH-<Unity Connection location identifier>@<domain generated according to Exchange Contact-creation policies>. Cisco Unity users can and should use this contact when addressing voice messages via ViewMail. Voice messages addressed to Unity Connection user email accounts rather than to their contacts are delivered as emails with voice attachments and do not light the user message waiting indicator or otherwise be accessible via Unity Connection.

If another Unity Connection user tries to address a voice message to the “Robin Smith - Voicemail” contact in the contacts list, this message is returned as undeliverable by default, because Unity Connection does not recognize the UCI_<alias>_BH-<Unity Connection location identifier>@<Cisco Unity site gateway domain> address as belonging to a Unity Connection user. To mitigate this issue, you can add the address as an SMTP proxy address for the user. (You can use Active Directory Users and Computers to export a list of Unity Connection contacts, then add SMTP proxy addresses to Unity Connection users in bulk using the Bulk Administration Tool. For information on using the Bulk Administration Tool, see the “Bulk Administration Tool” section of the “Tools” chapter of the System Administration Guide for Cisco Unity Connection, Release 10.x, available at http://www.cisco.com/c/en/us/td/docs/voice_ip_comm/connection/10x/administration/guide/10xcucsagx/10xcucsag190.html.

With the SMTP proxy address in place for Robin, other Unity Connection users can send voice messages to the “Robin Smith - Voicemail” contact. However, if a Unity Connection user tries to address an email to the contact, the email is returned as undeliverable.

Cisco Unity users have one entry in Active Directory even after the sites are linked. Users in either site can address voice messages to the entry in ViewMail for Outlook.

Note that if you select to synchronize one or more Unity Connection system distribution lists into a Cisco Unity Unified Messaging deployment, an Active Directory group is created for each list, which users can see in the contacts list. The group is created with the same configurable suffix (“- Voicemail” by default) added to the display name. As with the user contact entries, Unity Connection users who try to address messages to the group receives a non-delivery receipt in response. However, in this case, you cannot currently mitigate the issue for synchronized distribution lists using SMTP proxy addresses because you cannot configure SMTP proxy addresses for lists. To work around the issue, you have a couple of options:

• Do not synchronize Unity Connection system distribution lists to the Cisco Unity site. Instead, create any lists that Cisco Unity users need directly on the Cisco Unity site, adding Unity Connection contacts as members when necessary.
• Use multiple contact lists in Microsoft Exchange to segment addressing between Cisco Unity and Unity Connection users so that Unity Connection users do not have access to the addresses of groups that Cisco Unity creates for Unity Connection lists.

Note that while Unity Connection users should not address messages to Unity Connection system distribution lists using the group address-book entry, they can address messages to Unity Connection lists by entering the list address in the format <list alias>@<Unity Connection server SMTP domain>.