ATI00484IEN

Avaya IP Office Advanced Application and Troubleshooting Workshop

Chapter 9

VoiceMail Pro in SCN

Chapter 9 Module 1

Meshed Network

with IP Office

Module IntroductionThis module provides information about IP Office Small Community Network (SCN) features and configuration requirements.

After completing this module you will be able to:

Summarize the features of an IP Office SmallCommunity Network

Identify SCN hardware, software, licensing andconfiguration requirements

Describe the network configurations supported for andIP Office SCN

Configure a Small Community Network

Troubleshoot Small Community Network configuration issues

When connecting IP Offices together over IP or Packet based networks, Small Community Networking enhancesfeature transparency.

Small Community Network (SCN) OverviewWhen connecting IP Offices together over IP or Packet based networks, Small Community Networking enhances feature transparency. These networks can support up to a maximum of 1000 users across 32 sites.

The following additional features are available:

– Busy Lamp Field

– Camp-on

– Call Back When Free

– Paging

– Call Pick-up

– Centralized Voice Mail (Preferred Edition)

– Centralized Personal Directory0

– Centralized System Directory0

0 For 1400, 1600, 9600 and T3 Telephones as well as one-X Portal for IP Office

– Internal Directory

– Absence Text Message

– Anti-Tromboning

– Distributed Hunt Groups

– Remove Hot Desking

– Breakout Dialing

– Resilient SCN

– Centralized Call Log0

SCN Requirements For Small Community Networks VCM modules are required in all systems being connected.

The IP lines may be configured in a star or a meshed configuration.

Each IP Office system broadcasts UDP messages on Port 50795.

SCN is supported between IP Office systems with the same major software level or one level of difference in major software level. For example between 4.2 and 4.1 (same major level) and between 5.0 and 4.2 (one major level of difference).

If larger networks are required QSIG can be used to link multiple Small Community Networks together. Functionality between the communities is governed by the QSIG feature set.

SCN Requirements (Continued) QSIG, H.323 and SCN capabilities are not enabled by default in the IP500 and IP500v2.

On IP500 and IP500v2 systems Small Community Networking requires one or moreadditional licenses.

– An additional license is required to enable this functionality with 4 simultaneous networking channels.

– Additional channels can then be licensed in increments of 4.

– A Voice Networking license is required to enable TDM QSIG, even though there is no limit to the number of TDM QSIG calls that can be made or received once licensed.

Supported SCN Configuration: Star / Serial The following are examples of star and serial layouts. These are the only types of layouts

supported for Small Community Networks containing any pre-IP Office Release 5 systems.

The IP network supporting the SCN may be „meshed‟, but the IP Office configuration must use a star, serial or a star / serial combination configuration.

Supported SCN Configuration: Meshed The use of 'mesh' layout connections is supported for a Small Community Network beginning

with IP Office Release 5.

A mesh layout contains H.323 SCN Line routes between two or more IP Office control units.

Mesh, star and serial layouts can be combined.

Protocol ConsiderationsWhen deploying IP Office in a meshed environment there are some common protocols that may deployed to support the IP Network supporting the SCN:

Spanning Tree Protocol (STP): Layer 2 protocol that allows for network connection redundancy while preventing physical loops.

Multiprotocol Label Switching (MPLS): is a highly scalable, protocol agnostic, data-carrying mechanism where data packets are assigned labels and packet-forwarding decisions are made solely on the contents of this label. MPLS is often referred to as a "Layer 2.5" protocol.

Open Shortest Path First (OSPF): is a Layer 3 “link-state” routing protocol and is perhaps the most widely-used protocol in enterprise networks.

Routing Information Protocol (RIP)RIP is a simple method for automatic route sharing and updating within small networks. It allows alternate routes to be advertised when an existing route fails.

IP Office systems can utilize RIP on LAN1, LAN2 and individual services with thefollowing options:

– Listen Only (Passive): Listen to RIP1 and RIP2 messages and update the routing table, do not advertise routes.

– RIP1: Listen to RIP1 and RIP2 messages and advertises routes in a RIP1 sub-network broadcast.

– RIP2 Broadcast (RIP1 Compatibility): Listen to RIP1 and RIP2 messages and advertise routes in a RIP2 sub-network broadcast.

– RIP2 Multicast: Listen to RIP1 and RIP2 messages and advertise routes to the RIP2 multicastaddress (249.0.0.0).

Network Address Translation (NAT)NAT is the process of modifying network address information in IP packet headers while in transit through a router for the purpose of remapping a given address space into another.

NAT is useful as internally most networks use addresses that have been reserved for public use within networks but are not valid for routing across the internet and it allows multiple users to use the same address simultaneously (PNAT).

IP Office can use NAT on the LAN1 and LAN2 (WAN) interfaces to support data services and lines / trunks: H323 Line, IP DECT Line, SIP Line and SES Line.

The Static NAT table in the IP Office Firewall allows address translation between up to 64 selected internal and external IP address pairs.

Private Address SpaceThe Internet Assigned Numbers Authority (IANA) has reserved the following three blocks of the IP address space for private internets:

An enterprise that decides to use IP addresses as listed above can do so without any coordination with IANA or an Internet registry.

Private Address Space

Class IP Range

A 10.0.0.0 – 10.255.255.255

B 172.16.0.0 – 172.31.255.255

C 192.168.0.0 – 192.168.255.255

SCN SignalingWithin an SCN the separate IP Office systems 'learn' each other's extension numbers and user names.

IP Office SCN uses a signaling similar to RIP is order to update each other of there presence. This traffic can be seen in the IP Office System Monitor application as AVRIP packets.

Each IP Office system „listens‟ for AVRIP traffic on port 50795.

Each IP Office in the SCN transmits an update every 30 seconds.

Additionally BLF updates are transmitted when applicable up to a maximum of every 0.5 seconds. Typically the volume is less than 1Kbps per IP Office system.

SCN Configuration Requirements To set up a small community network, the following are required:

– H323 trunk(s) between the IP Office systems (H323 Line)

• On IP500 and IP500v2 systems, H323 trunks require the entry of IP500 Voice Networking licenses

– Data routing between IP Office systems (IP Route)

– The extension, user and group numbering on each system must be unique.

– The user and group names on each system must be unique.

– All systems should use the same set of telephony timers, especially the Default No Answer Time.

– Avaya recommends that all names and numbers (line, services, etc) on the separate IP Office systems are unique.

Bandwidth Calculator

H323 Trunk Configuration

Three Site SCN Example The table below shows the H323 Trunk configuration options for a three site SCN with a

meshed configuration.

IP Office SCN - Fallback IP Office Release 5 provides a number of features that allows IP Offices to provide fallback

functions for each other.

Each IP Office in the SCN can include one H323 line where the Supplementary Services is set to IP Office SCN – Fallback.

Once a line is set to IP Office SCN - Fallback, the following options are available:

– Backs up my IP Phones

– Backs up my Hunt Groups

– Backs up my Voicemail

Fallback is only intended to provide basic call functionality if the IP Office is not visible within the SCN for a period of more than 3 minutes.

IP Route Settings When an IP Office needs to send data to IP addresses on a different subnet, for example

another IP Office in a Small Community Network (SCN), the IP Route table is used by the IP Office to determine where data traffic should be forwarded.

This is done by matching details of the destination IP address to IP Route entries and then using the Destination specified by the matching IP route. These are referred to as 'static routes'.

Three Site SCN Example The table below shows the IP Route configuration options for a three site SCN with a

meshed configuration.

09-01 Meshed Network with IP OfficeTask 1: Configure and test a Small Community Network

1. Create H323 SCN Lines to partners

– Site A -> Site B and Site C

– Site B -> Site A and Site C

– Site C -> Site A and Site B

2. Place test calls between systems

Place test calls between systems

1. Configure one H323 Line for IP Office SCN – Fallback

– Site A -> Line to Site C

– Site B -> Line to Site A

– Site C -> Line to Site B

2. Register IP Phones to the IP Office (one IP Phone to each site)

3. Place test calls using the IP Phones between systems

09-01 Meshed Network with IP Office (Continued)4. Statically assign a 16 bit subnet mask (255.255.0.0) on the IP phone and unplug the Ethernet

cable from the LAN1 port of the IP Office.

5. The IP Phone at Site B should register to the IP Office at Site B

Note

For classroom purposes this step simulates a connectivity failure at Site B while leaving the network infrastructure in a working state. The Fallback will occur after a period of three minutes without connectivity between systems.

Note

It is assumed that the H323 Auto-Create Extn option is enabled at Site A

SummaryThis module provided information about IP Office Small Community Network (SCN) features and configuration requirements.

After completing this module you should be able to:

Summarize the features of an IP Office SmallCommunity Network

Identify SCN hardware, software, licensing andconfiguration requirements

Describe the network configurations supported for andIP Office SCN

Configure a Small Community Network

Troubleshoot Small Community Network configuration issues

Summary (Continued) Links to the documents used in this Learning Module:

– Small Community Networking

– SCN Configuration Requirements

– VoIP Calls Calculator

Chapter 9 Module 2

Centralized VoiceMail Pro

Module IntroductionThis module provides information on deploying a single voicemail server within a Small Community Network.

After completing this module you will be able to:

Summarize the configuration requirements for Centralized Voicemail

Describe the differences between Centralized Voicemail and Centralized Voicemail with Fallback

Configure Centralized Voicemail and Centralized Voicemail with Fallback

Within a Small Community Network, a single VoiceMail Pro server can be used to provide voicemail features for all the IP Offices in the SCN .

Centralized Voicemail OverviewWithin a Small Community Network, a single VoiceMail Pro server can be used to provide voicemail features for all the IP Offices in the SCN.

One IP Office is configured for operation with the VoiceMail Pro server as normal, including the license for voicemail operation and the features required. This IP Office is then regarded as the central IP Office for voicemail.

The other IP Office systems, the voicemail settings are configured to indicate that they get their voicemail services from the central IP Office. These IP Offices do not need licenses for voicemail (except for ContactStore and or UMS if required).

Caution: the use of centralized auto attendants can oversubscribe resources if notproperly designed.

Centralized Voicemail Diagram

Primary Link

SCN

SCN

SCN

Central Voicemail Location Settings

Voicemail Settings Remote Locations

Centralized Voicemail with Fallback IP OfficeWith Fallback IP Office links with Voicemail Server if primary IPO fails

Primary LinkFallback

SCN

SCN

Link activates when primary link fails

Central Location Settings

Remote Location Settings

Central IP Office Unit Fails

Link activates when primary link fails

SCN

Fallback SCN

Primary Link

Fallback IP Office Assumes Control

Primary link

09-02 Centralized VoiceMail ProTask 1: Disable VoiceMail Pro Service at remote sites

1. Determine which voicemail server will be used as the central server

2. At the „remote‟ sites (e.g. not the central site chosen above) Launch the Control Panel

– stop the Voicemail Pro Service and

– set the Startup Type to Manuel

09-02 Centralized VoiceMail Pro (Continued)Task 2: Configure Centralized VoiceMail

1. Configure the „remote‟ IP Office control units for Centralized Voicemail

2. Test access to voicemail from the „remote‟ sites

SummaryThis module provided information on deploying a single voicemail server within a Small Community Network.

After completing this module you should be able to:

Summarize the configuration requirements forCentralized Voicemail

Describe the differences between Centralized Voicemail and Centralized Voicemail with Fallback

Configure Centralized Voicemail and Centralized Voicemailwith Fallback

Summary (Continued) Links to the documents used in this Learning Module:

– Centralized Voicemail

– Fallback IP Office Control

Chapter 9 Module 3

Backup VoiceMail Pro

Module IntroductionThis module provides information on deploying a Centralized voicemail server and a backup voicemail server within a Small Community Network .

After completing this module you will be able to:

Summarize the configuration requirements for a backupvoicemail server

Configure a Backup voicemail server

For IP Office R6.0, the central IP Office hosting the VoiceMail Pro server can be configured with the IP address of a backupvoicemail server.

Backup Voicemail Server OperationFor IP Office R6.0, the central IP Office hosting the VoiceMail Pro server can be configured with the IP address of a backup voicemail server.

If the central voicemail server becomes unavailable to the network, the backup server will be used to provide voicemail services.

When the central voicemail server is restored, the central IP Office will switch back to using the central voicemail server for voicemail services and any new messages on the backup server are synchronized.

The backup voicemail server operates using the existing voicemail licenses installed in the central IP Office for normal operation.

The Backup Voicemail Server option requires the voicemail servers to be running VoiceMail Pro 6.0 or higher.

Centralized Voicemail with a Backup Server

SCN

SCN

Primary Link

Periodic Synchronization

SCN

Primary VMPro Server Fails

SCN

SCN

Primary LinkSCN

Link Establishes to Backup Voicemail Server

SCN

SCN

Primary Link

SCN

Primary Voicemail Server Restored

SCN

SCN

Primary Link

PeriodicSMTP

Synchronization

SCN

Backup Voicemail Server The VoiceMail Pro server software is installed as normal on the backup server PC.

The voicemail server is not specifically configured as being a backup server.

The Backup voicemail server must be configured for similar operation as the Central voicemail server, for example they must use the same mailbox modes (Intuity or IP Office) and have the same housekeeping settings.

SCN

Centralized Voicemail Server

Backup Voicemail

Server

IP Office (Centralized)

IP Office (Centralized)

Central IP Office (Voicemail Pro)

IP Office Voicemail Settings The Central server is configured with the IP address of the Backup server on the System |

Voicemail tab.

No additional licenses are required beyond those used already used for centralized voicemail.

The remote IP Offices in the Small Community Network are configured forcentralized voicemail.

Additional Server Requirements SMTP must be installed on both the Central and Backup voicemail servers.

IIS must be installed on both the Central and Backup voicemail servers so there is a Mail Dropfolder for exchanging files between servers.

The Mail Server field must point to the fully qualified machine name (e.g. vmserver.au.com) and not the IP address of the local machine.

Ensure the port used by SMTP (25) is not blocked by any security or firewall settings.

SMTP Testing An SMTP server is required for synchronization between the Central and Backup voicemail

servers.

Start a command line window by selecting Start | Run and entering cmd.

Type Telnet <VMServerName> 25.

The expected response is an SMTP reply code 220 indicating that the service is ready. For example: 220 < VMServerName > ESMTP server ready.

If a positive response is received, enter quit and press [Enter] to close the telnet connection to the SMTP server.

Test the connection in both directions between the Central and Backup voicemail servers.

SMTP Message Limit Ensure IIS Mail Server is not limiting mail size.

Deselect the SMTP server's Limit Message Size option in the Internet Information Services Manager application.

Verify Connections To minimize the dependence on corporate DNS servers it is a good practice to modify the local

hosts file with the IP address and host name of the Central and Backup voicemail servers:

– C:\Windows\System32\drivers\etc

Verify Connections (Continued) In the VoiceMail Pro Client on the Central server, Centralized Voicemail will be displayed in

the upper right hand corner of the screen.

On the Backup server, Backup Voicemail will be displayed.

The Type column will display Backup on the Centralized Server.

The Result column will display:

– Started

– In Progress

– Up-To-Date

09-03 Backup VoiceMail ProConfigure a Backup Voicemail Server

Task 1: Start the VoiceMail Pro Service

1. Determine which voicemail server will be used as the Backup server

2. At the site chosen for the Backup server Launch the Control Panel | Administrative Tools |Services

– start the VoiceMail Pro Service

09-03 Backup VoiceMail Pro (Continued)Task 2: Edit the “hosts” file

1. Edit the C:\Windows\System32\drivers\hosts file on the Central and Backup Voicemail servers

– add the IP address and fully qualified domain name (FQDN) for both servers

09-03 Backup VoiceMail Pro (Continued)Task 3: Ensure SMTP traffic is allowed

1. Ensure SMTP traffic is allowed in both directions by using Telnet to the FQDN of each server

09-03 Backup VoiceMail Pro (Continued)Task 4: Configure Central IP Office

1. Configure the IP address of the Backup server on the Central IP Office (requires reboot)

– Test steps on the next page.

Test the configuration step by step:

1. Open the VoiceMail Pro Client at the Central Site and select Distributed Voicemails

– The Backup Server information should be present

– The Result field should show Started, change to In Progress and Up-To-Date when synchronization completes

2. Leave a voicemail message for one or more users

3. Open the VoiceMail Pro Client at the Backup Site and expand the Navigation Tree to select Users

– After the synchronization occurs, there should be an update to the New column for the user(s) with a new message

– In the upper right hand corner of the screen the role should Backup Voicemail (Live) should display

09-03 Backup VoiceMail Pro (Continued)4. Stop the VoiceMail Pro Service at the Central Site

– The Backup voicemail server should become active after approximately three minutes

– Exit the VoiceMail Pro Client

5. Listen to the voicemail message(s) left for the user in Step 5 (do not delete message)

– On the VoiceMail Pro Client on the Backup server, the Last Accessed column should reflect the date and time the message was accessed.

6. Start the VoiceMail Pro Client at the Central Site and launch the VoiceMail Pro Client

– After a short period of time, the Central should resume the role of the Centralized Server

NOTE: Debug View can be used to monitor the output messages from the Central and Backup servers during this exercise

SummaryThis module provided information on deploying a Centralized voicemail server and a backup voicemail server within a Small Community Network .

After completing this module you should be able to:

Summarize the configuration requirements for a backupvoicemail server

Configure a Backup voicemail server

Summary (Continued) Links to the documents used in this Learning Module:

Backup Voicemail Server Operation

Chapter 9 Module 4

Distributed VoiceMail Pro

Module IntroductionThis module provides information on deploying a Distributed voicemail server within a Small Community Network .

After completing this module you will be able to

Summarize the configuration requirements for a Distributed voicemail server

Describe the differences between Centralized Voicemail and Centralized Voicemail with Fallback

Configure a Distributed Voicemail server

Distributed Voicemail Server OverviewFor IP Office R6.0, remote IP Offices in the Small Community Network can be associated with another voicemail server in addition to the centralized voicemail server.

The additional distributed server then provides all voicemail services (except message storage and collection) for that IP Office.

This requires the remote IP Office to have licenses for voicemail operation and the featuresit requires.

While the distributed server does message recording, it forwards all messages to the central voicemail server.

The messages are transferred between systems using an SMTP/MIME mail format to encode both the voice part of the message and additional message details.

Distributed Voicemail Server

SCN

SCNSCNCentral (Primary) Voicemail

Server (hosts voicemail for all sites Users and Hunt Groups

Distributed Voicemail (uses Central site for Users/HG and local server for AAs

Centralized Voicemail (using remote site for voicemail)

Summary of IP Office Configuration Settings The VoiceMail Pro server software is installed for each IP Office hosting a distributed

voicemail server.

All the voicemail servers must be configured for similar operation, for example they must use the same mailbox modes (Intuity or IP Office) and have the same housekeeping settings.

IP Office Settings Central IP Office Other IP OfficesIP Office with Distributed

Server

Voicemail Type Voicemail Pro Centralized Voicemail Distributed Voicemail

Voicemail IP AddressCentral voicemail server PC‟s IP address

Not usedDistributed voicemail server‟s IP address

Voicemail Destination Not usedOutgoing Group ID of the H323 Line to the Central IP Office

Outgoing Group ID of the H323 Line to the Central IP Office

Licenses

This system needs licenses for all the Voicemail Pro features required.

The other IP Offices only require licenses for UMSand or for ContactStore if required.

This system needs licenses for Voicemail Pro and voicemail features required.

SMTP Message Limit Ensure IIS Mail Server is not limiting mail size.

Deselect the SMTP server's Limit Message Size option in the Internet Information Services Manager application.

Additional Server Requirements SMTP must be installed on both the Central and Distributed voicemail servers.

IIS must be installed on both the Central and Distributed voicemail servers so there is a Mail Drop folder for exchanging files between servers.

The Mail Server field must point to the fully qualified machine name (e.g. vmserver.au.com) and not the IP address of the local machine.

Ensure the port used by SMTP (25) is not blocked by any security or firewall settings.

SMTP Testing An SMTP server is required for synchronization between the Central and Backup

voicemail servers.

Start a command line window by selecting Start | Run and entering cmd.

Type Telnet <VMServerName> 25.

The expected response is an SMTP reply code 220 indicating that the service is ready. For example: 220 < VMServerName > ESMTP server ready.

If a positive response is received, enter quit and press [Enter] to close the telnet connection to the SMTP server.

Test the connection in both directions between the Central and Distributed voicemail servers.

Verify Connections To minimize the dependence on corporate DNS servers it is a good practice to modify the local

hosts file with the IP address and host name of the Central and Distributed voicemail servers:

– C:\Windows\System32\drivers\etc

Verify Connections (Continued) In the VoiceMail Pro Client on the Central server, Centralized Voicemail will be displayed in

the upper right hand corner of the screen.

– On the Distributed server, Distributed Voicemail will be displayed.

– The Type column will display Distributed on the Centralized Server.

– The Result column will display; Started, In Progress or Up-To-Date.

09-04 Distributed VoiceMail ProConfigure a Distributed Voicemail Server

Task 1: Start the VoiceMail Pro Service

1. Determine which voicemail server will be used as the Backup server

2. At the site chosen for the Backup server Launch the Control Panel | Administrative Tools | Services

– start the VoiceMail Pro Service

09-04 Distributed VoiceMail Pro (Continued)Task 2: Edit the “host” file

1. Edit the C:\Windows\System32\drivers\hosts file on the Central and Backup Voicemail servers

– add the IP address and fully qualified domain name (FQDN) for both servers

09-04 Distributed VoiceMail Pro (Continued)Task 3: Add IP Address on Distributed Voicemail server

1. Edit the C:\Windows\System32\drivers\hosts file on the Distributed Voicemail servers

– add the IP address and fully qualified domain name (FQDN) for both servers

09-04 Distributed VoiceMail Pro (Continued)Task 4: Ensure IIS Mail Server is not limiting mail size

1. Ensure SMTP traffic is allowed in both directions by using Telnet to the FQDN of each server (like done in last module‟s exercise, also)

2. Ensure IIS Mail Server is not limiting mail size

– (Control Panel | Administrative Tools | Internet Information Services | Default SMTP Virtual Server | Properties)

09-04 Distributed VoiceMail Pro (Continued)Task 5: Configure the System | Voicemail tab for the Distributed server

1. Configure the System | Voicemail tab for the Distributed server

– Select the H323 Line number for the Central Site from the drop down box

– Enter the local IP address of the Distributed server PC (requires reboot)

Test steps on the next page.

09-04 Distributed VoiceMail Pro (Continued)Test the configuration step by step:

1. Open the VoiceMail Pro Client at the Central Site and select Distributed Voicemails in the Navigation Pane

– -The Distributed Server information should be present

– -The Result field should show Started, change to In Progress and Up-To-Date when synchronization completes

– By selecting Users and Hunt Groups in the Navigation Pane, the Users and Hunt Groups from the Distributed Site should be visible

2. Leave a voicemail message for a user or hunt group at the Distributed site

– The message should be stored in the message store of the Central voicemail server

3. Test a call flow / auto attendant at the Distributed site

– Use a call flow from a previous exercise or build a simple call flow for testing

– Use Debug View to verify the Distributed voicemail server is processing the call flow

NOTE: Debug View can be used to monitor the output messages from the Central and Backup servers during this exercise.

SummaryThis module provided information on deploying a Distributed voicemail server within a Small Community Network.

After completing this module you should be able to:

Summarize the configuration requirements for a Distributedvoicemail server

Describe the differences between Centralized Voicemail and Centralized Voicemail with Fallback

Configure a Distributed Voicemail server

Summary (Continued) Links to the documents used in this Learning Module:

Distributed Voicemail Servers

Congratulations!

You have completed the course.

Click 'Exit' on the lower left corner to exit the course.