WaveNet2

About WaveNet

With WaveNet, you can connect multiple Wave Servers so that selected users can be shared between Servers and can be seen and used as if they are on a single large system.

The following terminology is used throughout these topics:

•

A node is any Wave Server connected via WaveNet.

•

A local node is the node in a WaveNet network that you are connected to, either via a phone, ViewPoint, or the Wave Global Administrator Management Console. The local node is “local” from your point of view.

•

A remote node is another node in a WaveNet network to which you are not connected. A remote node is “remote” from the point of view of the local node.

•

A home node is the Wave Server where a local user was originally created.

•

A publishing node is the Wave Server from which information about local users is sent to one or more remote nodes.

•

A subscribing node is the Wave Server that receives information about users on other nodes.

•

A user is a Wave user on one of the Wave Servers in the WaveNet network:

•

A local user is a Wave user whose “home” is the local Wave Server.

•

A Gateway user is a Wave user whose “home” is another node in the WaveNet network, from the point of view of the local node. A Gateway user acts as a place holder, and is really an off-premise extension that points to the real user who is “local” on another Wave Server.

This section discusses the following topics:

About performing a system backup or restore on a WaveNet node

About users in a WaveNet network

By replicating local users on one Wave Server to other nodes in the WaveNet network, it appears as if the system administrator has added each user locally.

The following user information is replicated from a Gateway user’s home node to subscribing remote nodes:

•

User information. Name, extension, greetings, voice title, and so forth.

•

Personal status. Available, Do Not Disturb, In A Meeting, Out Of The Office, or On Vacation, or any other personal statuses that have been defined.

•

Availability. On-hook, off-hook, ringing.

•

Contacts. A Gateway user’s contacts that have PIN numbers are replicated to subscribing nodes. This allows a call to be identified as from that contact no matter which node in the WaveNet network handled the call. A voice message left by that contact at a remote node will also be identified as from the contact when it is delivered to the user’s home node voice mailbox. (Contacts that do not have PIN numbers, and any other contact information—for example, phone numbers—are not currently replicated.)

The following user information is transferred from remote nodes to a GateWay user's home node:

•

Voice Mail. Messages recorded on remote nodes are sent to the GateWay user's home node voice mailbox.

What happens when users are deleted from the network?

About performing a system backup or restore on a WaveNet node

What happens when users are deleted from the network?

About publication and subscription

The process of replicating users is called “publishing”. You publish one or more users from the Wave Server where those users live to other nodes. Publication pushes the user information listed above, as well as any subsequent updates to that information for those users, to the other nodes that you specify.

On each other Wave Server, a Gateway user is created for each published user. Those users are said to be “subscribed”.

Important! You do not need to publish all of the users on a Wave Server. Since initial publication and subsequent updates can generate a substantial amount of network traffic, you should publish only those users or extensions that need to be directly dialed from other nodes.

Publication steps are described in Publishing local users on remote nodes.

What happens when users are deleted from the network?

If you delete a published user from a node, that user’s off-premise extension representation is deleted from the subscribing node. When the last user published from a node is deleted, the SCP, routing table, and routing rule used to route calls back to that node are automatically deleted from the subscribing node.

About automatic trunking and routing configuration

When you publish the first local user to another node, WaveNet automatically sets up the following on the subscribing node:

•

One SIP signaling control point (SCP), used to route calls back to the Gateway user’s home node. (SIP signaling control points determine how IP calls are handled to and from specific IP addresses.)

•

One routing table with one SIP trunk routing rule per table.

All Gateway users published from that same node use the same SCP and routing table on the subscribing node.

In addition, the following is set up for each Gateway user on the subscribing node:

•

An off-premise extension representation. Either as a single off-premise extension, or as part of a range of an extension range.

About performing a system backup or restore on a WaveNet node

About performing a system backup or restore on a WaveNet node

When you perform a system backup on a Wave Server that is also a node in a WaveNet network, the WaveNet databases are included in the backup. See “Special Backup/Restore considerations on a WaveNet node” on page 1-1 for important information.

What information is transmitted when a call is transferred from one WaveNet node to another?

WaveNet calls are transmitted over SIP trunks from one node to another. All calls are normal SIP calls. The following information is transmitted when a WaveNet call is transferred from one node to another:

•

CallerID.

•

For a supervised transfer, this will be the transferring station’s Caller ID.

•

For a blind transfer, this will be original Caller ID associated with the call.

•

Destination extension, in the DID field. The original inbound call DID information is overwritten when the call is redirected via WaveNet.

•

VID. This value uniquely identifies the call when it is transferred across WaveNet nodes, and remains the same throughout the Wave network for the life of the call.

Important! No other information is transmitted with a call via WaveNet. Call notes, custom data, account codes, and other rich data fields are not transmitted between WaveNet nodes.

Note the following limitations in this version:

•

SIP trunking is the only currently supported trunk type.

•

Only one SIP SCP can be configured on a Wave Server that points to the same endpoint and port. See SIP signaling control point (SCP) issues for important information regarding this restriction.

•

A maximum of 1500 Gateway user subscriptions can be created per Wave Server.

•

A maximum of 100 Wave Servers can be added to a WaveNet network.

•

Network Address Translation (NAT) is not supported for use with WaveNet.

About performing a system backup or restore on a WaveNet node

Planning for WaveNet

Connecting multiple Wave Servers together via WaveNet requires thorough planning in order to have a smoothly running WaveNet network. This includes configuring the TCP/IP connectivity between network nodes, designing a global extension plan for users across all network nodes, configuring trunking and dialing access plans between nodes—all have to work together to make a WaveNet network easy to use.

This section discusses the following WaveNet planning topics:

TCP/IP connectivity between proposed nodes

•

Use static IP addresses. WaveNet requires that the IP address of each WaveNet node is a static IP address. Dynamic (DHCP) addresses are not supported.

•

Verify connectivity between nodes. Before WaveNet can be expected to communicate between nodes, it is essential to first establish that the network connections from each node to all other nodes are functioning properly.

Ping can be used in both directions between proposed WaveNet nodes to verify basic network connectivity between the nodes, but it will not determine if the MSMQ port and/or SIP ports are usable between the nodes (see the next bullet.)

•

Configure required ports between nodes. The following ports are required to support communication between WaveNet nodes:

•

Microsoft Message Queue (MSMQ). TCP Port 1801.

•

SIP ports. For details on how to set up SIP telephony on a Wave Server, see .

SIP signaling control point (SCP) issues

Trunking considerations

Important! In the current version, only SIP trunking is supported.

This section describes the following:

Trunking considerations With WaveNet, you can connect multiple Wave Servers so that selected users can be shared between Servers and can be seen and used as if they are on a single large system.

SIP signaling control point (SCP) issues

When you publish a user to one or more remote nodes, WaveNet automatically creates one SIP SCP on each remote node (as described in About automatic trunking and routing configuration.

Important! The current version does not support two SCPs that point to the same endpoint and port. (An “endpoint” is a Wave Server, a WaveNet node, or another system.) The IP Telephony applet in the Global Administrator Management Console will not allow you to create such duplicates, and WaveNet will not automatically create any duplicate SCPs.

You may have pre-existing non-WaveNet SCPs to support off-premise extensions, external dialing, private networking, and so forth. If any of these pre-existing SCPs point to any of the Wave Servers that you plan to add as nodes in the WaveNet network, and they are configured to use the same port as the default SIP listener port on those nodes, you must manually delete the pre-existing SCPs or move them to a different port, to allow WaveNet to create the SCPs that it needs to point to these nodes in order to deliver calls to published Gateway users.

After the WaveNet SCPs have been automatically created, you can do either of the following to restore off-premise extensions, external dialing, or private networking previously associated with any SCPs that were deleted:

•

Create new SCPs with the same endpoint address, but with different ports.

•

Share the WaveNet SCPs for those other purposes. Note that while the WaveNet SCPs can be used this way, they cannot be edited in any way. This method is not recommended, because future changes might create a confusing situation involving the WaveNet created SCPs.

Example: Centralized Trunking SCPs

If SIP trunking between WaveNet nodes is required to deliver calls to a node with centralized trunking, then define a separate reciprocal pair of SCPs using a different port. Each node should have a new non-WaveNet SCP defined with the endpoint address of the reciprocal node, but use a different port (examples: 5061, 5070, etc.) Route calls for the centralized trunks (or any other non-WaveNet purposes) over this non-WaveNet pair of SCPs.

Dial plan considerations

Defining a comprehensive dialing plan is critical to the success of your WaveNet network, as well as for continued or future support of non-WaveNet dialing functionality.

This section describes the following:

Local and network extension plan issues

No two extensions, whether local user extensions or Gateway user extensions, can be exactly the same if they are shared to the same node. Careful planning can avoid future “collisions” of duplicate extension numbers when users are published to other nodes that will then need to be resolved one by one.

•

Number of extensions required. How many local user extensions do you need? How many Gateway user extensions do you need?

•

Extension length. Extension length determines the maximum number of extensions possible locally, and across the network. Any WaveNet location-based prefixes, for example “Store Number” should be taken into consideration when deciding on extension length.

•

Same length. Making both local user extensions and Gateway user extensions the same length is easiest to explain to users, because there is no difference between dialing a local user vs. a published Gateway user. However, you must ensure that there are no duplicated extensions anywhere.

•

Different lengths. You may need to implement extensions of different lengths if you are using a prefix system, since the prefix will be prepended onto the local extensions before they are published. Users may find it confusing to have to dial extensions of different lengths depending on whether they are dialing a local user or a published Gateway user. However, there is no risk of duplication between local user extensions and Gateway user extensions.

Dial plan considerations With WaveNet, you can connect multiple Wave Servers so that selected users can be shared between Servers and can be seen and used as if they are on a single large system.

First Digit Table issues

You need to carefully coordinate the First Digit Tables of all the nodes in the network. In order for any Wave extension (local user extension or Gateway user extension) to be dialed successfully:

•

The first digit of that extension must match an entry in the First Digit Table.

•

That First Digit must be configured as Extension.

•

The extension length for that First Digit must match the actual length of the extension.

For example, for extension 3005 to be dialed successfully, the following entry must be defined in the First Digit Table:

Digit (Type) = 3 (Extension)

Extension Length = 4

When you publish one or more local users to a remote note, the extensions of those users are compared against the First Digit Table on the subscribing node. WaveNet will not accept a publication request when the First Digit Table on the subscribing node cannot meet the requirements listed above.

The possible scenarios are:

•

First digit not yet configured. If the first digit of a user’s extension is currently not in use (set to Not Configured) in the First Digit Table, WaveNet automatically updates the First Digit Table and sets the digit type to Extension and extension length to the actual length of the user’s extension. The publication request for this user is accepted, and the corresponding Gateway user is created on the subscribing node.

•

First Digit configured as Extension with correct length. If the first digit of a user’s extension is currently in use and set to Extension in the First Digit Table, the length of the user’s extension is compared to the Extension Length for that First Digit.

•

If the lengths match, the publication request for this user is accepted, and the corresponding Gateway user is created on the subscribing node.

•

If the lengths do not match, the publication request is rejected with the error “User Exception - First Digit Length”.

•

First Digit configured as Attendant or External. If the first digit of a user’s extension is currently defined and set to Attendant or External in the First Digit Table, the publication request is rejected with the error “User Exception - Already in Use”.

Important! If the publication request is accepted (either because the First Digit was previously Not Configured, or was configured as Extension with the correct length), WaveNet flags that First Digit as “Protected”, to prevent any inadvertent changes that would prevent Gateway users whose extension matches that first digit from being dialed.

Dial plan considerations With WaveNet, you can connect multiple Wave Servers so that selected users can be shared between Servers and can be seen and used as if they are on a single large system.

External dialing issues

A First Digit Table entry set to External defines 1-2 digit access code used to make an external call.

Note the following:

•

Digit combinations used for external dialing cannot be duplicated by any Gateway user extensions used with WaveNet.

•

Any SCP currently used for external dialing that points to a Wave Server that is also a WaveNet node must be manually deleted or moved to a different port before publishing any users to that Server.

With WaveNet, you can connect multiple Wave Servers so that selected users can be shared between Servers and can be seen and used as if they are on a single large system.

Non-WaveNet off-premise extension issues

Before deploying WaveNet, you may have already configured off-premise extensions that you want to continue using, or you may want to create them in the future for purposes unrelated to WaveNet.

As long as there are no duplicate extension numbers, non-WaveNet off-premise extensions are supported on the same Wave Server as the ones that WaveNet creates automatically for Gateway users published from other nodes.

•

If any non-WaveNet off-premise extensions already exist on a Wave Server with the same extensions as users that will be published from any other nodes in the WaveNet network, those off-premise extensions must first be deleted or assigned a different extension number before publication will be successful.

•

If you want to create new non-WaveNet off-premise extensions on a Wave Server that is a node in a WaveNet network, you must either:

•

Assign extension numbers to the new off-premise extensions that do not duplicate any existing subscribed Gateway users’ extensions.

•

Delete the subscribed Gateway users before creating the non-WaveNet off-premise extensions using those extension numbers.

Also, any SCP currently used for off-premise extensions that points to a Wave Server that is also a WaveNet node must be manually deleted before publishing any users to the Server.

With WaveNet, you can connect multiple Wave Servers so that selected users can be shared between Servers and can be seen and used as if they are on a single large system.

Private networking issues

To dial an extension via a private network, a user must dial the following:

•

External access code of 2 or more digits to access the private network.

•

Location code of 2-6 digits to identify the Wave Server of the extension being dialed.

•

Called party’s extension.

A WaveNet network and a private network can coexist, however note the following:

•

External access code + location code + called party extension digit combinations used for private networking cannot be duplicated by any Gateway user extensions used with WaveNet.

•

Any SCP currently used for private networking that points to a Wave Server that is also a WaveNet node must be manually deleted before publishing any users to the Server.

For details on setting up a private network, see Configuring private networking.

With WaveNet, you can connect multiple Wave Servers so that selected users can be shared between Servers and can be seen and used as if they are on a single large system.

Virus-scanning issues

It is important to achieve a balance between ensuring a secure and virus-free environment while also not interfering with the reliability and performance on each Wave Server. One contributing cause of application and service outages or system performance issues may be not configuring adequate exclusions if you use virus-scanning software.

Current best practice is to exclude the following Microsoft Message Queue (MSMQ) folders from virus scanning:

%SystemRoot%\system32\MSMQ

%SystemRoot%\system32\MSMQ\storage

Important! Applying this exclusion is at your discretion. Applying any exclusion to your virus-scanning configuration may make your Wave Server or your network more vulnerable to attack by malicious users or by malicious software such as viruses. Before making any changes, it is recommended that the risks associated with configuring virus-scanning exclusions be evaluated thoroughly. Depending on the specifics of your environment, additional settings may be required to prevent reliability and/or performance issues.

Installing WaveNet

Once your Wave Server meets the requirements listed below, the WaveNet applet in the Global Administrator Management Console will be operational—no additional installation steps are required.

Perform the following steps on each Wave Server that will be added as a node in the WaveNet network.

Make sure that each Wave Server in the WaveNet network meets the following requirements:

•

Install or upgrade the Wave Server to the required versions. For the latest information, contact your Vertical provider.

•

Purchase, enter, and activate required one WaveNet license per Wave Server. For more about Wave licenses, see Entering and Activating Wave Licenses.

Obtain the following logon accounts:

•

A logon account with Enterprise rights on your Wave Server.

•

Logon accounts for other nodes:

•

If you are adding your Wave Server to an existing WaveNet network. Obtain an Enterprise logon account from any other node in the network.

•

If you are building a new WaveNet network. Obtain an Enterprise logon account from each other Wave Server that you will add as a node.

Note: Providing valid credentials when adding a Wave Server helps ensure that only approved nodes are added to the network.

Manually eliminate off-premise extension conflicts:

•

Local off-premise extension conflicts. Delete any off-premise extensions configured on your local Wave Server that would be duplicated by Gateway user extensions to be published from remote nodes to your local Wave Server.

•

Remote off-premise extension conflicts. Delete any off-premise extensions configured on remote nodes that would be duplicated by Gateway user extensions that you plan to publish to those remote nodes after you add your local Wave Server to the WaveNet network.

See Non-WaveNet off-premise extension issues for more information.

Manually eliminate First Digit Table conflicts.

•

Local First Digit Table conflicts:

•

Any local First Digits that match the first digit of any Gateway user extensions that will be published on the local Wave Server, must either be Unassigned, or set to Extension, with the correct length for those Gateway user extensions.

•

Any local First Digits set to External that utilize an SCP that points to a Wave Server that is also a WaveNet node must be manually deleted before publishing any users to the Server. Once the WaveNet SCP has been automatically created, the First Digit can be re-added sharing the WaveNet SCP to restore external dialing.

•

Remote First Digit Table conflicts:

•

Any remote node First Digits that match the first digit of any Gateway user extensions that will be published on the those remote Wave Servers, must either be Unassigned, or set to Extension with the correct length for those Gateway user extensions.

•

Any remote node First Digits set to External that utilize an SCP that points to a Wave Server that is also a WaveNet node must be manually deleted before publishing any users to the Server. Once the WaveNet SCP has been automatically created, the First Digit can be re-added sharing the WaveNet SCP to restore external dialing.

See First Digit Table issues for more information.

Manually eliminate SCP conflicts to prevent possible inbound SIP call routing problems.

•

Local SCP conflicts. For any remaining SCPs on the local node that point to other Wave Servers that are also WaveNet nodes (for example SCPs used for off-premise extensions, private networking, and so forth), manually delete those SCPs or move them to a different port than the default SIP listener port on those nodes.

•

Remote SCP conflicts. For any remaining SCPs on any remote node that point to other Wave Servers that are also WaveNet nodes (for example SCPs used for off-premise extensions, private networking, and so forth), manually delete those SCPs or move them to a different port than the default SIP listener port on those nodes.

See “SIP signaling control points (SCPs) issues” in Trunking considerations for more information.

In the General Settings applet, on the PBX (Advanced) tab select the Allow Trunk-To-Trunk Connections checkbox. (This setting allows inbound calls on the Wave Server to be routed to Gateway users on other WaveNet nodes.)

If you are using anti-virus software, configure that software to exclude the following Microsoft Message Queue (MSMQ) folders from virus scanning:

%SystemRoot%\system32\MSMQ

%SystemRoot%\system32\MSMQ\storage

Adding a Wave Server to the WaveNet network

Configuring WaveNet

To configure WaveNet, you use the WaveNet Management applet, available on the Applications tab of the Global Administrator Management Console.

This section describes how to do the following:

Testing connections between WaveNet nodes

Testing connections between WaveNet nodes

Adding a Wave Server to the WaveNet network

You can add your local Wave Server or any other Wave Server to the WaveNet network, or create a new WaveNet network by adding each Wave Server.

To add a Wave Server to the WaveNet network, you add it to one other node according to the following instructions. When a node is added to one node, it is automatically joined to all other nodes that are already connected.

To add your Wave Server to the WaveNet network

If necessary, click the Applications tab of the Management Console.

Click WaveNet Settings, located in the WaveNet section.

The WaveNet Management screen opens:

The Wave Servers that have already been added to the WaveNet network are listed in the left pane. The Wave Server to which you are running WaveNet Management is identified as “(Local Server)”.

To add a Wave Server to the WaveNet network, click Add. The Add Server dialog opens:

Enter the following information:

•

Communications Method. Select TCP.

•

Server. Enter the Wave Server’s name or IP address.

•

Username and Password. Enter valid Enterprise logon account credentials:

•

If you are adding your local Wave Server to an existing WaveNet network, enter Enterprise logon account credentials from any other node in the network.

•

If you building a new WaveNet network, enter Enterprise logon account credentials for the Wave Server that you are adding.

Click OK. The new Wave Server is displayed in the left pane.

If the Wave Server cannot be added to the network, one of the following error messages is displayed.

Note: The actual text of these error message may change by the time that WaveNet is officially released.

Table 0-1
Error Message	Cause/Action
Unable to add requested server: Invalid user name or password	The Wave Server cannot be added to the WaveNet network, because the user name and/or password entered in the Add Server dialog are invalid, or that account does not have Enterprise-level rights. Retry using correct account information, or another account with Enterprise-level rights.
Invalid host name.	The Wave Server cannot be added to the WaveNet network, because the Wave Server’s name or IP address entered in the Add Server dialog is invalid. Try again using the correct host name.
Maximum number of WaveNet servers are connected to destination.	The Wave Server cannot be added because the current maximum of 100 Wave Servers per WaveNet network has been reached. You cannot add another Wave Server to the WaveNet network until you remove one of the existing nodes.

Adding a Wave Server to the WaveNet network

Testing connections between WaveNet nodes

You can test the connection between any two WaveNet nodes from any node in the WaveNet network.

To test the connections between WaveNet nodes

To test the connection between your local node and one or more remote nodes, select the local Wave Server in the left pane of the WaveNet Management screen.

Expand Diagnostics for the selected Server.

Click Connection Test. The nodes connected to the selected Wave Server are listed in the right pane.

Select the checkboxes for each connection that you want to test. Click Select All to test all of the connections displayed.

Click Test Connection. The right pane is updated with the results of the test:

Response time indicates in milliseconds the time that it took for a test message to be sent round-trip between the testing and responding node:

•

Green. Connection is functioning normally.

•

Yellow. Connection is slow.

•

Red. Connection timed out.

Response times are shown for the following types of separate communications between WaveNet modes:

•

Availability. On-hook, off-hook, and ringing changes for Gateway users.

•

User. User information about Gateway users (names, titles, greetings, personal status, contacts, and so forth). This information is sent when users are first published and if the information changes later.

•

Command. WaveNet administrative commands (Join, Delete, Publish, Unpublish, Test Connectivity, Activity, and so forth) between nodes.

Resolve any issues or timeouts identified. For example:

•

Check that non-WaveNet network communications to the affected Wave Servers are functioning normally.

•

Verify that the problem Wave Servers are up and running.

•

Verify that WaveNet is running correctly (not stopped, no errors, and so forth) on the problem nodes.

Select another Wave Server in the left pane and repeat these steps to test the connections between that node and other nodes.

How publishing requests are processed

Publishing local users on remote nodes

You can publish local users from any Wave Server displayed in the left pane of the WaveNet Management applet to one or more other nodes.

Once a user has been successfully published, that user will be displayed in the Subscribed Extensions list for each node that you specified. Note that even though you publish users via a named extension group, the users are listed individually in the Subscribed Extensions list.

Adding a Wave Server to the WaveNet network

Testing connections between WaveNet nodes

How publishing requests are processed

A new publication request is queued on the home node of the user to be published to other nodes. WaveNet operates at a relatively lower priority than call processing on a Wave Server. On a quiet system or network without much phone activity, publication will complete almost instantaneously. On a very busy system or network, there may be some delay before publication is complete, with subscribed Gateway users displayed for remote nodes and any errors displayed in the Publication Error list for the Gateway user’s home node.

To publish local users as Gateway Users on remote nodes

In the left pane of the WaveNet Management screen, select the Wave Server from which you want to publish users.

Select Published Extensions. Any users that have already been published from this Wave Server are listed in the right pane.

For those users, the following information is displayed:

•

Extension Group Name. Name you specified when you created the list of users to publish.

•

Extension Range. Extensions you added to the Extension Group.

•

Destination Server. Node to which the users were published.

Click New. The Published Extensions Group dialog opens:

Enter the following information:

•

Extension Group Name. Name of the group of extensions to publish.

•

Extensions to Publish. List of extensions to publish.

•

Publish to Servers. Wave Servers where the selected users will be published.

Click OK.

In the left pane, expand Published Extensions, and then click Errors to see if any publication requests were rejected because of First Digit or extension conflicts. Since publication may not complete immediately on a very busy system or network, click Refresh Now to refresh the information displayed in the right pane.

For information about how to resolve publication errors, see Resolving publication errors. After you resolve any errors, select an entry and click Retry. If there is no longer any conflict, the entry is removed from the table.