When the messaging needs of your organization require more than one Unity Connection server or cluster, you need a way to combine multiple Unity Connection directories or to ensure that the connected servers can communicate with each other. The concept of networking, HTTPS Networking, is introduced to connect different Unity Connection servers and clusters in a network.

Note	The legacy (SMTP) and new HTTPS networking are not supported simultaneously in the same network.

In hub-spoke topology, all the directory information among the spokes is shared through the hub(s) connecting the spokes. For example, in the above figure, if spoke A needs to synchronize directory information with spoke E, the directory information flows from spoke A to hub B, hub B to hub C, hub C to hub D, and then from hub D to spoke E.

Each Unity Connection server (or cluster) is represented in the network as a single Unity Connection location, which is created locally during installation and which cannot be deleted from the server itself. When you join the server (or cluster) to an existing location in a network, a Unity Connection location is automatically created for the server (or cluster).

Note	In an HTTPS network the round-trip latency should not be more than 250 ms between Hub and Spoke nodes.

Note	HTTPS networking supports single site networks only. You cannot connect multiple HTTPS networks or single site networks together to form a larger network. The maximum number of Unity Connection locations that you can connect in an HTTPS network is 25.

When deciding which OVA template to deploy, it is important to determine the role of the servers in your environment relative to HTTPS networking. For example, if you are building a VPIM server to support 150,000 VPIM users, you would use the largest OVA template, and the server would only contain VPIM accounts, not subscribers.

Due to the limitations of the smaller OVA templates, you need to take careful consideration of growth as well as whether the node is a hub or spoke in the network when choosing your OVA. If your network size grows past the directory size limits of your chosen OVA, you need to rebuild or replace your servers with larger Novas to accommodate the larger directory size. It is a good idea to select a larger template than you think you need for just this reason. The smallest OVA template, in most cases, should only be used for spoke servers in the network.

For information about the maximum number of locations and other directory objects supported in a Unity Connection site, see the “Directory Object Limits” section in the System Requirements for Cisco Unity Connection, Release 12.x, at http://www.cisco.com/c/en/us/td/docs/voice_ip_comm/connection/12x/requirements/b_12xcucsysreqs.html

Currently, the only supported method of migrating from legacy networking to HTTPS networking is a manual method. In the future, there is a migration tool available to make the process easier. The migration method is outlined in the HTTPS Networking Guide for Cisco Unity Connection , Release 12.x.

For information about the migration method, see the “Migration from Legacy network to HTTPS Network” chapter in the HTTPS Networking Guide for Cisco Unity Connection , Release 12.x, at https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/connection/12x/https_networking/guide/b_12xcuchttpsnet.html.

If your organization has more users than a single Unity Connection server or cluster pair can support, you can join two or more Connection servers or clusters (up to a maximum of ten) to form a well-connected network, referred to as a Connection site. The servers that are joined to the site are referred to as locations. (When a Connection cluster is configured, the cluster counts as one location in the site.) Each location is said to be linked to every other location in the site via an intrasite link. Figure 5-2 illustrates a site of five Connection locations joined by intrasite links.

Intrasite networking is supported only with Cisco Business Edition 6000/7000.

Within a site, Unity Connection locations automatically exchange directory information, so that a user on one location can dial out to or address messages to a user on any other system by name or extension, provided that the target user is reachable in the search scope of the originating user. The networked systems function as though they share a single directory. Users do not need to know where another user is located; they need only the name or extension number to address a message to any user or system distribution list in the directory.

Because intrasite links use SMTP transport for both directory replication and message transport, Unity Connection locations in a site can be deployed across geographic boundaries. Each server that is joined to the site must be able to access all other servers in the site directly through TCP/IP port 25, or SMTP messages must be routable among the servers through an SMTP smart host.

If your site includes a Unity Connection cluster, you must have a smart host available to resolve the SMTP domain of the cluster to both the publisher and subscriber servers in order for message traffic to reach the cluster subscriber server in the event that the publisher server is down.

In a site, each Unity Connection object is created and homed on a single Unity Connection location. An object can only be modified or deleted on the location where it was created. Each location has its own directory of users and other objects, and replicates a subset of these objects and their properties to other locations.

The following objects are replicated in a Unity Connection site:

• Users

• Administrator-defined contacts (including those associated with a VPIM location)

• System distribution lists (including membership)

• Locations (Unity Connection and VPIM)

• Partitions

• Search spaces

• Recorded voice names

For information about the maximum number of locations and other directory objects supported in a Unity Connection site, see the “Directory Object Limits” section in the System Requirements for Cisco Unity Connection, Release 12.x, at https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/connection/12x/requirements/b_12xcucsysreqs.html

You can also optionally deploy additional cross-server features between locations in a site. Cross-server sign in allows all users to dial the same number when calling from outside the organization to sign in to Unity Connection, regardless of which Unity Connection server they are homed on. Cross-server transfer enables calls from the automated attendant of one Unity Connection location to be transferred to a user on another networked Unity Connection location, according to the call transfer and screening settings of the called user. When you enable cross-server transfer, cross-server live reply is also enabled, allowing users to return calls to message senders who are users on other networked Unity Connection locations, according to the call transfer and screening settings of the called user.

The Unity Connection site concept was known as a Digital Network in release 7.x. You can join 7.x locations, 8.x locations, and 9.x locations, 10.x locations, 11.x locations and 12.x locations in the same Unity Connection site, as long as you do not link the site to any other site.

For more information on intrasite networking, see the “Overview of Networking Concepts” chapter of the Networking Guide for Cisco Unity Connection, Release 12.x, at http://www.cisco.com/c/en/us/td/docs/voice_ip_comm/connection/12x/networking/guide/b_12xcucnetx.html .

You can use an intersite link to connect one Unity Connection site to another Unity Connection site, allowing you to scale your organization from a maximum of ten locations to a maximum of twenty. The linked sites are referred to as a Cisco Voicemail Organization.

To create an intersite link, you select a single location from each site to act as a gateway to the other site. All directory synchronization communications and voice messages pass between the two site gateways, thereby limiting the connectivity requirements and bandwidth usage to the link between those two site gateway locations. The gateways use the HTTPs protocol to exchange directory synchronization updates. Intersite voice messages are transmitted and received via SMTP.

Figure 5-3 illustrates the role of the site gateways and the intersite link in connecting two Connection sites.

Only one intersite link is supported per site. (This restriction applies to all types of intersite links, so you cannot link a Unity Connection site to another Unity Connection site and also to a Cisco Unity site.) In order to link a Unity Connection site to another site, all Unity Connection locations in the site must be running Unity Connection release 8.0 or later. Intersite Networking is not supported for use with Cisco Business Edition.

As with intrasite networking, users, system distribution lists, partitions, search spaces, and Unity Connection locations are replicated between sites. (System distribution list replication is optional.) However, contacts, system distribution list membership, and VPIM locations are not replicated between sites. Also, site gateways do not relay VPIM messages to other sites. Therefore, to deploy VPIM in the entire organization, you must independently configure each site for VPIM.

All of the optional cross-server features that are available within a Unity Connection site (cross-server sign in, cross-server transfers, and cross-server live reply) are also available between sites.

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 can continue to provide message exchange over the intersite link if the publisher server is down. Note that in this configuration you must have a smart host available to resolve the SMTP domain of the cluster to both the publisher and subscriber servers in order for message traffic to reach the cluster subscriber server in the event that the publisher server is down.

For more information on intersite networking, see the “Overview of Networking Concepts” chapter of the Networking Guide for Cisco Unity Connection, Release 12.x, at http://www.cisco.com/c/en/us/td/docs/voice_ip_comm/connection/12x/networking/guide/b_12xcucnetx.html.

Unity Connection introduces a new option for internetworking Unity Connection and Cisco Unity servers—you can use intersite networking to connect a Unity Connection server, cluster, or site to a Cisco Unity server, failover pair, or digital network. The network of Unity Connection and Cisco Unity servers is referred to as a Cisco Voicemail Organization.

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 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 Microsoft Exchange 2007 server configured with the Hub Transport role. (For up-to-date version support and requirements for the Interoperability Gateway, see the Networking Options Requirements for Cisco Unity (Version 5.x and Later) at http://www.cisco.com/en/US/docs/voice_ip_comm/unity/compatibility/matrix/cunetoptionsreqs.html.)

Figure 5-4 depicts—at a high level—the role of the Interoperability Gateway for Microsoft Exchange, the site gateways, and the intersite link in connecting Unity Connection and Cisco Unity sites.

Note that in order to link Cisco Unity and Unity Connection sites, all servers in the Unity Connection site must be running Unity Connection 12.x. Intersite Networking is not supported for use with Cisco Business Edition.

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 7.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 for Cisco Unity, see the Networking Options Requirements for Cisco Unity (Version 5.x and Later) at http://www.cisco.com/en/US/docs/voice_ip_comm/unity/compatibility/matrix/cunetoptionsreqs.html.

When you link a Cisco Unity site and a Unity Connection site, a contact is added to the Cisco Unity directory and to Active Directory for each Unity Connection user. Likewise, a user is added to the Connection site global directory for each Cisco Unity user. 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. Also, the site gateways do not relay messages for other types of networking (AMIS, Bridge, VPIM, and so on) across the intersite link. To deploy VPIM in the entire organization, you must independently configure each site for VPIM.

You can choose whether to replicate system distribution lists between sites, and choose which lists to replicate. 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.

All of the optional cross-server features that are available within a Unity Connection site or Cisco Unity Digital Network (cross-server sign in, cross-server transfers, and cross-server live reply) are also available between the sites.

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.

For more information on intersite networking, see the “Overview of Networking Concepts” chapter of the Networking Guide for Cisco Unity Connection, Release 12.x, at http://www.cisco.com/c/en/us/td/docs/voice_ip_comm/connection/12x/networking/guide/b_12xcucnetx.html.

The Avaya Message Networking solution (or the Avaya Interchange) uses a hub-and-spoke topology to allow voice messaging between systems, using a number of protocols, thus allowing a voice messaging system such as Cisco Unity Connection to send and receive network voice messages with any other system in the network. Unity Connection uses the VPIM protocol to communicate with the Interchange, and the Interchange takes care of routing the messages to and from other systems on the network using the applicable protocol. Figure 5-5 illustrates an example topology.