Lotus Sametime Unified Telephony: Installation Guide

Lotus Sametime
Version 8.5.1.2
Lotus Sametime Unified Telephony

Installation Guide

Note
Before using this information and the product it supports, read the information in "Notices."
Edition notice
This edition applies to version 8.5.1.2 of IBM Lotus Sametime Unified Telephony (program number 5724–U79) and
to all subsequent releases and modifications until otherwise indicated in new editions.
© Copyright IBM Corporation 2009, 2011.
US Government Users Restricted Rights – Use, duplication or disclosure restricted by GSA ADP Schedule Contract
with IBM Corp.
Contents
Chapter 1. Sametime Unified Telephony Configuring Telephony Application Servers . . . 167
overview . . . . . . . . . . . . . . 1 Initializing the persistent cache on a Telephony
Sametime Unified Telephony PDF library . . . . . 1 Application Server . . . . . . . . . . 167
Solution overview . . . . . . . . . . . . 1 Establishing trust between Telephony
Features and functions . . . . . . . . . . 2 Application Servers and Lotus Sametime servers 171
Supported interfaces, protocols, PBXs, and Configuring the dial plan . . . . . . . . . 173
gateways . . . . . . . . . . . . . . 4 Example dial plan . . . . . . . . . . . 174
Component overview . . . . . . . . . . . 5 Creating office codes . . . . . . . . . . 175
Telephony Application Server. . . . . . . . 6 Creating Home DNs . . . . . . . . . . 177
Media Server overview . . . . . . . . . . 8 Different numbering plans available . . . . . 180
Telephony Control Server. . . . . . . . . 10 Configuring business groups . . . . . . . 182
Deployment scenarios . . . . . . . . . . . 11 Creating numbering plans . . . . . . . . 185
Minimal server deployment . . . . . . . . 11 Creating default unified number feature profiles 187
Multiple TAS server deployment with Standby Creating a queue device . . . . . . . . . 187
TAS . . . . . . . . . . . . . . . . 12 Creating call routing components. . . . . . 195
Deployment with IP PBX environment . . . . 13 Adding subscribers for testing. . . . . . . . 210
Deployment with non-IP PBX environment . . . 13 Conducting simple call tests . . . . . . . . 211
Configuring conferencing . . . . . . . . . 212
Enabling conferencing on the Media Server . . 213
Chapter 2. Installing . . . . . . . . . 15 Updating the dial plan . . . . . . . . . 217
Hardware installation . . . . . . . . . . . 15 Configuring conferencing resources on TAS . . 230
Setting up hardware for a Telephony Control Modifying endpoint in CLI . . . . . . . . 235
Server . . . . . . . . . . . . . . . 15 Testing conference features . . . . . . . . 240
Setting up hardware for a Telephony Application Configuring security . . . . . . . . . . . 243
Server . . . . . . . . . . . . . . . 26 Enabling TLS encryption for the deployment 243
SAN deployment . . . . . . . . . . . 31 Configuring SUT SIP proxy/registrar security 247
Software installation . . . . . . . . . . . 46 Configuring TLS trunks . . . . . . . . . 250
Installing Telephony Control Server . . . . . 46 Configuring advanced features . . . . . . . 251
Installing Telephony Application Servers . . . 62 Localizing announcements . . . . . . . . 251
Starting and stopping services . . . . . . . 124 Configuring CDR and call records . . . . . 261
Verifying the installation . . . . . . . . 126 Setting up 911 . . . . . . . . . . . . 261
Deploying Lotus Sametime Unified Telephony to Communications Assistance for Law
users . . . . . . . . . . . . . . . . 127 Enforcement Act . . . . . . . . . . . 262
Preparing the Sametime client . . . . . . . 127 Setting up speed dial lists . . . . . . . . 263
Setting up voice mail . . . . . . . . . . 263
Chapter 3. Configuring . . . . . . . 129
Configuring the Telephony Control Server. . . . 129 Notices . . . . . . . . . . . . . . 265
Command-line interface tasks . . . . . . . 129 Trademarks . . . . . . . . . . . . . . 267
CMP (Common Management Portal)
configuration tasks . . . . . . . . . . 142
© Copyright IBM Corp. 2009, 2011 iii

iv Lotus Sametime Unified Telephony: Installation Guide
Chapter 1. Sametime Unified Telephony overview
IBM® Lotus® Sametime® Unified Telephony provides the integration of telephony
across multivendor Private Branch Exchange (PBX) systems resulting in a unified
end-user experience, including integrated softphones; phone and IM presence
awareness; call control and rules-based call management.
Sametime Unified Telephony PDF library

Help for IBM Lotus Sametime Unified Telephony is available in PDF format.
Guide Description
Lotus Sametime Unified Telephony The Quick Start Guide provides an overview of the
8.5.1/8.5.1.2Quick Start Guide installation requirements and process for deploying
Lotus Sametime Unified Telephony.
Lotus Sametime Unified Telephony The Functional Specification includes a description of
8.5.1.2 Functional Specification Lotus Sametime Unified Telephony software
capabilities and benefits, as well as a summary of user
and administrator features. The specification describes
supported languages and product architecture,
including detailed server specifications for the
Telephony Control Server, the Telephony Application
Server, and the Media Server. The functional
specification also describes the storage area network
and IP network connections. The specification also
includes information on interoperability and testing.
Lotus Sametime Unified Telephony The Installation Guide provides detailed information
8.5.1.2 Installation Guide on installing and configuring Lotus Sametime Unified
Telephony 8.5.1.2, including: hardware, operating
systems, primary servers, and failover servers.
Solution overview
Enterprises need to deliver products and services faster to enhance customer
service and speed decision making. Companies are finding that a key to improving
productivity and business responsiveness is delivering communication and
collaboration tools in a consistent and meaningful context. By integrating
telephony into the company's greater communications platform, decision making
and handling business processes are accelerated. The telephony integration allows
person-to-person as well as multi-person interaction.
IBM Lotus SametimeUnified Telephony software offers the immediacy of instant

messaging with telephone capabilities on users' desktops, so that users can find,
reach, and collaborate with one another more effectively. Telephony features with
integrated presence awareness, softphones, call control, and rules-based call
management can be used with a wide variety of telephone systems. The
middleware layer of Unified Telephony software provides connectivity to multiple
telephone systems – both IP private branch exchange (PBX) and legacy
time-division multiplexing (TDM) systems – independent of the enterprise's
telephony infrastructure or migration to IP telephony.
© Copyright IBM Corp. 2009, 2011 1

Features and functions
This section describes the benefits and features contained in IBM Lotus Sametime
Unified Telephony.
Benefits
v Helps users access telephony functionality from within real-time collaboration
software. The front-end user capabilities in IBM Lotus Sametime Unified
Telephony software are designed to be intuitive and ease access to telephony
functionality from within the Lotus Sametime client.
v Provides users a simple, consistent user communications experience including
telephony presence, incoming call management and call control, click to call and
softphones. Within a single client, users have the same functions and user
experience independent of the phone system to which they are connected. Users
can see if colleagues are available and then reach them more reliably and
effectively without having to find different numbers for different locations.
v Fosters communication and collaboration within applications to help speed
business processes for users. Lotus Sametime and IBM Lotus Sametime Unified
Telephony software allow communication and collaboration in a meaningful
context that accommodates work-style preferences. Users can access and manage
their communications from a Lotus Sametime or IBM Lotus Notes client; a
Microsoft Outlook, Microsoft Exchange, or Microsoft Office application; or an
enterprise application.
v Helps optimize the value from existing enterprise applications and telephony
systems - independent of the telephony infrastructure or migration to IP
telephony. The software integrates both IP PBX and legacy TDM systems.
v Helps reduce calling costs with softphone, call management, and aggregated
presence awareness. Calls made through the softphone feature avoid PBX
telephone charges. Call management capabilities can direct calls to a user's
preferred device so that colleagues do not have to call various devices to find
the user. The aggregation of presence information - a user's availability for
instant messaging or a telephone call - helps colleagues avoid making
unnecessary calls or calls that cannot be accepted by a user. The
click-to-conference feature can reduce cost of expensive audio-conferencing
services for improvised conferences
Features
v Presence awareness - including telephony status. At a glance, users can see
telephone status (for example, on the phone, off the phone) along with online
presence status (for example, available, away, in a meeting, do not disturb),
making it easy to know whether it is appropriate to initiate a real-time
conversation through instant messaging or a phone/conference call.
v Telephony and voice — The front-end user capabilities in Lotus Sametime
Unified Telephony software are designed to be intuitive and ease users' access to
telephony functionality from within the Lotus Sametime client. The software
combines the immediacy of instant messaging with telephone capabilities, right
on users' desktops. Users can see if colleagues are available and then reach them
more reliably and effectively without having to look up their numbers — even if
they are on the move.
– Softphone users can initiate and manage phone calls through their PC
microphone and speakers using the Lotus Sametime Unified Telephony
embedded softphone.
– Click to Call and Click to Conference — Users can initiate a call or audio
conference through a PBX telephone system by selecting one or multiple
2 Lotus Sametime Unified Telephony: Installation Guide

names from the contact list. Users who are collaborating through an instant
message can escalate from instant messaging to a call or audio conference by
using the click-to-call, click-to-conference capability.
– Incoming call management — With Lotus Sametime Unified Telephony
software, users focus on the people they need to reach — not where they are
or what device they are using. Users can have a single unified phone number
that allows calls to be routed automatically to their current location and the
device they are currently using. Users can easily set rules and preferences to
direct their calls — such as redirecting a call to a mobile phone. Because
Lotus Sametime software has presence and location awareness, Lotus
Sametime Unified Telephony software can automatically set the preferred
contact device based on availability and location status.
– Call control — The software includes call control capabilities for participants
and moderators.
- Participant call controls
v Click to Call
v Click to Conference
v accept, reject, or redirect incoming call
v transfer/forward call
v raise/lower volume
v mute/unmute
v move call to another device
v Call Merge
v hold/resume
v disconnect
- Moderator call controls
v mute one or all participants
v lock call
v invite others
v end call for everyone
– A simple, consistent user communications experience on the desktop client.
Sametime Unified Telephony software provides the same set of functionality
and user experiences to supported users, independent of the phone system to
which they are connected. And, it provides these capabilities from within a
single client. Other offerings provide a softphone that only works with a PBX
from a specific vendor and that require a full migration to IP telephony before
delivering a common set of unified communications collaboration capabilities
to users.
v A platform for unified communications and collaboration
– The back-end middleware layer of Lotus Sametime Unified Telephony
software masks the complexity of back-end integration by providing
connectivity to multiple telephone systems.
– The software connects through Session Initiation Protocol (SIP) to
SIP-compliant PBXs from multiple vendors using SIP, and it connects to
legacy TDM phone systems through SIP gateways.
– Technology and telecommunications managers can extend their existing
telephone systems — rather than replacing them — to provide the same set of
unified communications functionality to supported users regardless of the
phone systems they access.
Chapter 1. Sametime Unified Telephony overview 3

– The middleware approach can help enterprises deliver the value of unified
communications to virtually all users — even if they have not yet completed
a migration to VoIP telephony.
– Lotus Sametime Unified Telephony software is designed for reliability and
scalability from hundreds of users to hundreds of thousands.
The call control elements are designed to provide high availability, helping to
assure that calls can be completed. Other elements of the system support
redundancy, clustering, and load balancing to help optimize performance and
continue to provide service to users in the event of component failure.The
included IBM Tivoli® System Automation for Multiplatforms (SAMP) software
provides advanced policy-based automation for applications and services
across heterogeneous environments to help provide high levels of availability
and reduce the frequency and duration of service disruptions.
– Lotus Sametime Unified Telephony software provides tools for configuring,
monitoring, and managing your deployment. A browser-based configuration
interface aids the configuration of the telephony control, application and
Media servers, as well as the definition of business groups, number plans and
feature profiles. Administration consoles can be used to check server status; to
monitor call volume, user call activity and license usage; and to view and edit
SIP proxy properties.
Supported interfaces, protocols, PBXs, and gateways

This section lists the supported interfaces, protocols, PBXs, and gateways for
theIBM Lotus Sametime Unified Telephony product.
The list of interfaces and PBXs that are supported by Sametime Unified Telephony
are included in the Sametime Unified Telephony system requirements.
Protocols
v Proprietary protocol
– Virtual Places (VP) - A proprietary protocol used in Sametime for
communication between clients and server applications and the Sametime
server.
v Standard protocols:
– Hypertext Transfer Protocol (HTTP) - A communications protocol for the
transfer of information about the Internet.
– Session Initiation Protocol (SIP) - A signaling protocol used for setting up and
tearing down multimedia communication sessions.
– Media Gateway Control Protocol (MGCP) - A signaling and call control
protocol used within a distributed Voice over IP system.
– Simple Object Access Protocol (SOAP) - A simple XML-based protocol to let
applications exchange information over HTTP.
– Computer-Supported Telecommunications Applications (CSTA) - An
abstraction layer for telecommunications applications.
– SIMPLE
– T.120
– XMPP
– H.323

PBX
v IP PBX – Voice over a data network and interacts with the normal public
switched telephone network (PSTN)
v Telephony Gateway – Telecommunications network node that can interface with
another network that uses different protocols, as follows:
– PSTN– Network of the world's public circuit-switched telephone networks.
– TDM PBX – Time-Division Multiplexing used for circuit mode communication
with a fixed number of channels and constant bandwidth per channel.
Gateways
v Siemens Gateway
– SIP gateways for Non-IP PBX sites
– Gateway RG8702 - two E1/T1 ports - 60 or 46 IP channels
– Gateway RG8708 - eight E1/T1 ports - 240 or 184 IP channels
– Gateway RG8716 - 16 x E1/T1 ports - 480 or 368 IP channels
– Software RG7800
v Dialogic Gateway
– DMG2030DTI - one E1/T1 port - 30 IP channels
– DMG2060DTI - two E1/T1 ports - 60 IP channels
– DMG2120DTI - four E1/T1 ports - 120 IP channels
Component overview
This section describes the components that make up the IBM Lotus Sametime
Unified Telephony product including servers, clients, and external telephony
equipment.
The following graphic shows the various components and how they work together.

The major components are discussed in separate topics:
v Telephony Application Server
v The Media Server
v Telephony Control Server
Lotus Sametime Standard Server
IBM Lotus Sametime Standard server lets a community of users to collaborate in

real-time activities such as online meetings, presence, chat, and VoIP over and
intranet or the Internet.
Lotus Sametime Connect Client
The Lotus Sametime Connect client is the end-user client for letting community
users collaborate in real-time activities: presence, chat, and VoIP over an intranet or
the Internet.
External Telephony Equipment

v IP PBX – The business telephone system that delivers voice over a data network
and interacts with the normal public switched telephone networks (PSTN).
v PSTN – The network of the world's public circuit switched telephone networks.
v Telephony Gateway – A telecommunications network node that can interface
with another network that uses different protocols.
Telephony Application Server

The Telephony Application Server provides telephony services to the Sametime
Unified Telephony users through the Sametime Connect client. The Telephony
Application Server interfaces with Sametime Community server, enterprise
directory, and Telephony Control Servers.
The Telephony Application Server (TAS) executes the workflow for handling the
calls of the users. The Telephony Application Server (TAS) executes the workflow
for handling the calls of the users. Users must be provisioned to a specific
Telephony Application Server before they can use IBM Lotus Sametime Unified
Telephony. The Telephony Application Server is notified when a user logs on to the
Lotus Sametime Connect and a channel opens to the user and notifies the user that
the telephony service is available.
There can be up to eight Telephony Application Servers on each SUT installation.
Each Telephony Application Server monitors up to 15,000 users. User affinity is

established when a person logs on to the Sametime server with a Sametime
Unified Telephony client. Once the Sametime server notifies the Telephony
Application Server of the event, the Telephony Application Server opens a channel
to the Sametime Connect client that enables the Sametime Unified Telephony
features.
Users can provision as many preferred devices and phone numbers for themselves
as they like. The Telephony Application Server can ring any of these devices based
on rich presence and user rules that allow the user to determine what device they
want to ring according to any combination of time, location, and presence status.
Telephony Application Servers are deployed with at least one warm standby server

to provide redundancy for server failure. One warm standby server can be used to
provide redundancy for one or all eight Telephony Application Servers. If higher
redundancy is required, the number of warm standby servers can be increased to
match the number of Telephony Application Servers.
Components
SIP Proxy/Registrar
The Session Initiation Protocol (SIP) is a protocol for creating, modifying,
and terminating sessions with one or more Lotus Same Unified Telephony
users. SIP uses elements called proxy servers to help route requests to the
user's computer, to authenticate and to authorize users. SIP also provides a
registration function that lets users send their current locations for use by
the proxy servers.
Presence Adapter
This component publishes telephony presence to the Lotus Sametime
community.
Communications Adapter
This component starts and manages two-party and conference calls. The
communication adapter keeps the Lotus Sametime Connect client informed
of the IP address of the SIP registrar.
Media Server
This component provides tones and announcements for teleconference
messages.
Administration
This component displays the status of the main components and provides
real-time monitoring of user sessions and registered devices.
REST API
The Representational State Transfer Convention (REST) is the standard for
building web services. The REST interface allows for Click-To-Call and
conference integration with third-party applications.
Functions
Telephony Application Server performs the following functions:

v Runs all application logic that manages the workflow associated with routing
incoming calls so that they are always routed to the preferred device.
v Initiates all call-related events to the client. If the Sametime Connect client is
online, the Telephony Application Server initiates a popup window that lets the
user answer an incoming call with the current preferred device or deflect the call
to another device.
v Provides personal call history records of all calls that user makes and receives.
v Handles all call and flow control for audio conferences.
v Manages all user and configuration data.
v Some data is provisioned into the system as part of the initial configuration,
while other data is managed by the user.
v Together with Media Server component provides limited audio conferencing
capability. Primary use case is for small ad-hoc meetings. This capacity is
configurable.
v Provides ability to provision remote administrative features.
v Provides SIP Registrar and Proxy service for the embedded softphones.

Media Server overview
The Media Server is an application that is installed on to the Telephony
Application Server and integrates into the Telephone Control Server Framework.
The Media Server can be installed on its own hardware. The more dedicated the
hardware, the better the Media Server performance.
The Media Server hosts and executes the following services:

v Provides announcement services for the Telephony Control Server in different
languages.
v Supports the following audio-codecs, and can transcode between different codes:
– G.711 A-Law (Europe and the rest of the world)
– G.711 µ-Law (North American and Japan)
– G.729 AB
Every Media Server node can handle up to a certain number of media channels. A
media channel is an active call with an active RTP-based media steam.
Media Server Scalability

The following table shows media server scalability according to the server profile.
It displays required hardware, RAM, and the maximum rate of calls per hour at
the busiest time of the day.
Table 1. Media Server Scalability by server profile
Server Max. G.711 Max. G.729
Profile CPU RAM (GB) Channel Channel BHCA rate
Small server Dual-Core 4 150 50 3,000
system, for
example, Intel
Xeon 3060 or
5030 (>= 2.33
GHz)
Midrange Quad-core 4 300 100 6,000
Server system, for
example, Intel
Xeon 5345
(>= 2.33
GHz)
High-End Octo-Core 8 500 160 10,000
Server system, for
example, 2
Intel Xeon
5345 (>=2.33
GHz)
Each Telephony Application Server is provided with a single-accompanying Media

Server to handle the media server needs of that Telephony Application Server.
When scaling up to multiple Telephony Application Servers with their

corresponding Media Server, the Telephony Control Server must be configured to
use the Media Server used for the tones and announcements of the users
configured on a specific TAS.

The following graphic shows a typical Lotus Sametime Unified Telephony
environment that can support up to 100,000 users. This support requires the use of
seven Telephony Application Servers, each supporting up to 15,000 users and at
the center is a Duplex Telephony Control Server system.
Note: One TAS server is used as a failover server in this diagram but it is not
active until required.
The Sametime server supports 30,000 - 50,000 users depending on the operational
profile. The Sametime cluster support can be scaled as needed.
A Telephony Application Server can be connected to one Sametime server or a

cluster community.
Media Server Conferences:
Media Servers support ad-hoc conferencing. Users can initiate conference calls and
the conference bridge in the Media Server dials out to participants. Once the
ad-hoc conference has been started by the user, the conference bridge in the Media
Server can accept inward dialing into the conference bridge. The Media Server
conferences feature has its own set of specifications:
v There is no fixed limit to the number of simultaneous ad-hoc conferences. The
limit is based on the maximum number of total conference participants allowed.
v The Media Server transcodes between different codecs if needed.
v The number of conference participants in a single conference can be configured.
The default number of users is 6.
v An onboard Media Server can handle 400 concurrent conference legs. For
example, there can be 100 conferences with 4 people each, or 80 conferences
with five people each, and so on.
Media Server: Offboard
A Sametime Unified Telephony cluster supports up to eight external or offboard

Media Servers. The ratio of TAS to Media Servers is always one-to-one. There is a
limit of eight Telephony Application Servers to one Telephony Control Server.

Note: You can configure the Telephony Control Server itself to use a separate
Media Server for tones and announcements. However, this Media Server cannot be
used for conferences.
For failover purposes, the TAS and Media Server must be on the same subnet.
Telephony Control Server

In an IBM Lotus Sametime Unified Telephony deployment, the Telephony Control
Server is responsible for receiving incoming requests. The Telephony Control
Server also provides the unified number service and handles all incoming call
routing for the unified number. The Telephony Control Server container is a
back-to-back user agent (B2BUA) with a PBX abstraction layer that allows it to
work with Telephony Application Server.
Specifications
The Telephony Control Server handles VoIP connections. This server is part of a
duplex configuration that serves as a failover system. The Telephony Control
Server is always deployed in a duplex configuration with RAID hard disk drives
to provide high availability.
The Telephony Control Server provides the unified number facility that informs the
Telephony Application Server about receiving a call from the unified number of a
user. It also uses that number for any calls the user makes through Lotus Sametime
Connect client. The unified number is the single telephone number for routing calls
to the telephony devices of the user.
The Telephony Control Server uses the CSTA (Computer Supported

Telecommunications Application) to communicate with the Telephony Application
Server, where call-related events are triggered and handled. When a call comes in
to Telephony Control Server and is a unified number, Telephony Control Server
notifies the Telephony Application Server through CSTA. The Telephony Control
Server also expects the Telephony Application Server to return the number where
the call is routed. All this communication happens through CSTA.
The Telephony Control Server has the following functional components:

v SIP B2BUA – The SIP back-to-back user agent (B2BUA) is the user agent to both
end points of a SIP call. B2BUA handles all SIP signaling between the end point,
from call initiation to call termination.
v CSTA – The abstraction layer of Lotus Sametime UnifiedTelephony allows
interactions on a telephone and a computer to be integrated.
v Hardware: IBM System x3550 M2. This is the only supported hardware for a
Telephony Control Server in this release.
– The Lotus Sametime Unified Telephony Connect software cannot be installed
to any other server.
– This part number comes with a predefined set of adapters and a
configuration, including two 146 GB SCSI hard disks configured into RAID
and with two redundant power supplies.
– Use of this specified part number ensures that all the correct components are
shipped with the server and that the configuration matches what has been
tested by IBM software development and performance test teams.
v Operating System: SUSE Linux Enterprise Server version 10 SP3 64 bit is
included in the Lotus Sametime Unified Telephony software bundle.

v Software: The Telephony Control Server is packaged in the Telephony Connect
component of Lotus Sametime Unified Telephony.
v Telephony Control Servers have eight Gigabit Ethernet ports and require two
sets of physical Ethernet switches with three Virtual LANs (Billing, Management
and Signaling). They also require two direct server-to-server interconnect cables
to assure high availability.
v Two Telephony Control Servers must be on the same layer two subnet with the
following requirements:
– The network links used for interconnects must have low latency and low
error rates.
– The interconnects must not be used on any network that might experience
network outages of 5 seconds or more.
v Telephony Control Server can handle up to 100,000 users. Telephony Control
Server can handle up to 15,000 SIP trunks.
v Telephony Control Server acts as SIP B2BUA between PBXs (IP PBXs and Non IP
PBXs through SIP gateways).
v Telephony Control Server can connect to the PSTN through SIP gateways. The
TCS® is connected to IP PBXs, non-IP PBXs, and gateways through SIP trunks.
v Telephony Control Server can support up to eight active Telephony Application
Servers and eight warm standby servers. The number of users cannot exceed
100,000 users.
Deployment scenarios
The following sections describe the supported deployment scenarios for the
Sametime Unified Telephony system.
The supported deployment scenarios are as follows:
Minimal server deployment

This section describes the minimal IBM Lotus Sametime Unified Telephony
deployment. IT consists of two Telephony Application Servers for failover, a single
Media Server, and a standard duplex Telephony Control Server cluster.
The Sametime clients are connected to a Domino Sametime server, a Telephony

Application Server configured for failover, and a Media Server which can be
hosted on the Telephony Application Server or on a separate server.
The Telephony Application Server is connected to the Telephony Control Server

which in turn is connected to the normal array of PBX equipment: desk phones,
time-division multiplexing phones, and VoIP phones made up of IP and cell
phones that are connected to the IP-PBX system.

This minimal deployment is sufficient for up to 15,000 users.
Multiple TAS server deployment with Standby TAS

This section describes a multiple Telephony Application Server IBM Lotus
Sametime Unified Telephony deployment with a standby TAS. This failover
solution employs a standby Telephony Application Server that comes online when
another TAS fails. The failover solution is implemented using IBM Tivoli® System
Automation for Multiplatforms (SAMP).
The basis for this system is the storing of all the individual TAS application
configuration details on separate partitions on a storage area network (SAN).
When a particular Telephony Application Server fails, the standby Telephony

Application Server is pointed to a location on the SAN from which it loads the
required configuration settings and applications.
The time IT takes for the Telephony Application Server system to restore itself is
directly proportional to the user base that it needs to reload.
Deployment with IP PBX environment

Lotus Sametime Unified Telephony software supports connectivity to multiple,
mixed PBX environments. Lotus Sametime Unified Telephony software is designed
to support connections to SIP-compliant PBX, using the following SIP RFCs: 3261,
3264, 4566, and to PBXs supporting Primary Rate Interface (PRI) and Basic Rate
Interface (BRI) using gateways.
All calls routed to the desk-phones must be intercepted by the Sametime Unified
Telephony system. Based on Sametime Unified Telephony Subscriber rules, the call
is then routed. There is a gateway between the PBX and the phones.
Calls made to the PBX system are now routed through the Sametime Unified
Telephony system and then routed to the desk top. The customer can choose to
keep the current telephone numbers or get a new set of numbers for the Sametime
Unified Telephony installation. Most customers elect to keep their current numbers
to avoid disruption in their communications environment. The telephone numbers
are converted into Sametime Unified Telephony format, which can include a
special prefix. The call gets directed to the preferred client device.
v Calls routed from the PBX to the desk phones no longer reach the desk phones
directly, but instead are routed to Sametime Unified Telephony.
v Calls from Sametime Unified Telephony destined for desk phones are routed to
the phones directly.
v Calls from Sametime Unified Telephony to anywhere else are routed to the PBX
(and then to the PSTN if needed).
v Calls from desk phones can be routed directly back to the PBX which route to
Sametime Unified Telephony if needed.
Deployment with non-IP PBX environment

Sametime Unified Telephony deployment on a non-IP PBX is the simplest
Sametime Unified Telephony installation. It requires that calls are intercepted
between the PBX and the desk phone.
Calls placed on the phones are routed through the non-IP PBX to other phones or
to the Public Switched Telephone Network (PSTN).
All calls out to the desk-phones must be intercepted and the calls redirected to the
Sametime Unified Telephony system. Sametime Unified Telephony then decides,
based on subscriber rules, where the call is routed. There are several options.
v If the non-IP PBX has a SIP interface, it could act like a gateway between the IP
and the Time Division Multiplexing (TDM) world, as the integration point.
v If there is no SIP interface available on the PBX, the use of a SIP Gateway is
possible. The proposed gateway must be compatible with the existing TDM
traffic and there can be no known interoperability issues between the gateway
and the non-IP PBX.

Chapter 2. Installing
This section provides an overview of the installation prerequisites, a checklist, and
the installation tasks for the Lotus Sametime Telephony product.
Hardware installation
Hardware technical information relating to the Telephony Control Server and the
Telephony Application Server.
Setting up hardware for a Telephony Control Server

Set up the hardware needed for a Telephony Control Server in an IBM Lotus
Sametime Unified Telephony deployment.
The Telephony Control Server runs on an IBM xSeries® 3550 M2, using SuSE
Enterprise Linux Server version 10 SP3. Install Telephony Control Server in pairs to
provide backup and failover services; each server can be cabled in a
switchover/failover style or directly to the network. For technical specifications,
see the Sametime Unified Telephony system requirements.
TCS hardware installation checklist

This section lists all the hardware requirements for the TCS.
Hardware checklist
The Telephony Control Server hardware checklist:

v Inventory and inspect the hardware.
v Locate the IBM xSeries server printed documentation and digital media.
v Perform a power on test.
v Attach the slides to the rack and place the servers onto the slides.
v Connect all cables.
v Modify the SCSI RAID configuration
v Modify the server BIOS settings.
v Update firmware.
v Power-Supply AC or DC (Hot swappable)
The basic system sometimes come with the memory and additional NIC cards.
These cards are packaged separately and need to be inserted into the server. The
dual port and Quad port Gigabyte Ethernet cards must be placed in specific PCI
slots.
Telephony Control Server cabling

This section describes the Telephony Control Server cabling for simplex and duplex
systems in an IBM Lotus Sametime Unified Telephony deployment.
You will need the following items:

v 2 x Power-Supply AC or DC (Hot swappable)
v Remote Management with Intel BMC

v 2U rack-optimized 20" deep chassis
The dimensions of the server are as follows:

v Height (imperial/metric) – 3.5 in/87.6 mm
v Width (imperial/metric) – 17.14 in/ 435.0 mm
v Depth (imperial/metric – 20.0 in/508.0 mm
There are at least eight cables used in connecting a single x3550 M2 server. Six
cables are connected to the network and two cables serve as crossover cables to be
connected to the second x3550 M2 server.
Configuring BIOS Settings

When installing the Telephony Control Server hardware for an IBMLotusSametime
Unified Telephony deployment, you must configure the BIOS settings.
Procedure
1. Turn on the server.
It make take a few minutes for the server to start up and display the IBM
System x screen.
2. When the IBM System x screen appears, press the F1 key to run the Setup
program.
3. On the System Configuration and Boot Management screen, selectDate and

TIme.
Tip: Refer to the banner at the bottom of the Setup screens for information on
how to navigate the Setup program and manipulate the data on the various
screens. Some of the Setup screens display screen specific help in the right
column of the screen.

4. On the Date and Time screen:
a. Ensure that the date and time settings are correct; change them as
necessary.
b. Press the Esc key to return to the System Configuration and Boot
Management screen.
5. Back on the System Configuration and Boot Management screen, select

System Information.
Chapter 2. Installing 17
6. On the System Information screen, select Product Data.
7. On the Product Data screen:
a. Verify that the version levels of the Host Firmware, Integrated
Management Module, and Diagnostics are at least at the levels listed in the
following screen:
If any of the versions are not up to the level listed, consult the IBM System
X documentation for information concerning the update of drivers and
firmware.
b. Press the Esc key to return to the System Configuration and Boot
Management screen.

8. Back on the System Configuration and Boot Management screen, select Boot
Manager.
9. On the Boot Manager screen:
a. Select Change Boot Order.

b. On the Change Boot Order screen, change the order to match the order
showing in the following screen:
c. Press the Enter key to save your changes.
d. Press the Esc key to exit the Setup screens until you have backed up to the
System Configuration and Boot Management screen.
10. Do one of the following:
v If you will proceed to set up the RAID unit as described in the next task,
leave the System Configuration and Boot Management screen open.
v Otherwise, press the Esc key to exit the Setup program.
Configuring the RAID unit setup

When installing the Telephony Control Server hardware for an IBM Lotus
Sametime Unified Telephony deployment, you must configure the SCSI RAID and
create a disk mirror.
Before you begin
You must have set up the BIOS on the server before you can configure the SCI
RAID.
About this task
A new server is accompanied by an IBM ServerGuide software. It contains all the

necessary drivers for the server type and model. You can boot the server using the
CD and it takes you through setting up the date and time, and the RAID
controller. It also primes the server with the correct hard disk drivers (SCSI) for the
required operating system.
You can download the software from the IBM Support site.
If you do not have the IBM ServerGuide software available, you can set up the
SCSI RAID unit and create a disk mirror as follows:

Procedure
1. If you are not currently in the Setup program, reboot the server (either cycle
the power or press the Ctrl-Alt-Del keys simultaneously) and press F1 at IBM
System x screen.
2. On the System Configuration and Boot Management screen, select System

Settings.
Tip: Refer to the banner at the bottom of the Setup screens for information on
how to navigate the Setup program and manipulate the data on the various
screens. Some of the Setup screens display screen specific help in the right
column of the screen.
3. On the System Settings screen, select Adapters and UEFI Drivers.
4. On the Adapters and UEFI Drivers screen, press the Enter key to refresh the
list of adapters and drivers.

5. When the Adapters and UEFI Drivers screen refreshes, scroll down to LSI
Logic Fusion MPT SAS Driver and select it.
6. On the Adapter Properties screen, select RAID Properties.
7. On the Select New Array Type screen, select Create IM Volume.
8. On the Create New Array screen:

Notice that initially, both drives have RAID Disk set to No and Drive Status
left blank:

a. Use the arrow keys to select the first drive in the pair.
b. Use the + (plus) or - (minus) key to change its RAID Disk setting to Yes
and its Drive Status to Primary.
c. Now use the arrow keys to select the second drive in the pair.
d. Use the + (plus) or - (minus) key to change its RAID Disk setting to Yes
and its Drive Status to Secondary.
The settings should now look like the following screen:
9. Press the C key to initiate mirroring for the array.
The mirroring takes a while; however there is no need to wait because the
mirroring will continue in the background. You can proceed immediately to
the next step.
10. Select Apply changes and exit menu to create the array.
11. Press the Esc key to close out all of the preceding screens, until you have
backed up to the System Configuration and Boot Management screen.
Attention: Be sure to save any configurations when prompted.
Setting up hardware for a Telephony Application Server

Set up the hardware needed for a Telephony Application Server in an IBM Lotus
The Telephony Application Server runs on an IBM System x® using the SuSE Linux
10 SP3 operating system. For technical specifications, see the Sametime Unified
Telephony system requirements.
TAS hardware installation checklist

This section lists all the hardware requirements for the TAS.
Hardware checklist
The Telephony Application Server hardware checklist:

v Inventory and inspect the hardware.
v Locate the printed documentation and digital media for the server.
v Perform a power on test.
v Attach the slides to the rack and place the servers onto the slides.
v Connect all six cables. Modify the SCSI RAID configuration
v Modify the server BIOS settings.
v Remote Console Startup through a Web Browser.
v Check to see if a RAID card is installed in the top full-height PCI slot of the IBM
x3550M2. Refer MOP located in KMOSS how to remove the RAID controller
card.
Telephony Application Server cabling

This section describes the Telephony Application Server cabling.
v 2 x Power-Supply AC or DC (Hot swappable)
v Remote Management with Intel BMC
v Rack-optimized 1U
BIOS Settings
During the installation of the TAS hardware, you must also perform BIOS settings.
Before you begin
Determine that all the hardware works as expected. The Remote Management
Controller (iRMC) must be configured.
About this task
You can enter the BIOS by pressing the F2 key during the Startup process.

Procedure
1. Change the Startup Sequence to the following order Boot Settings Priority:
a. IDE - DVD ROM
b. SCSI - RAID LUN
c. Legacy Only
d. Remove all other boot items (such asUSB, Floppy, PSX, network) in order to
avoid other possible delays or hangs during boot.
2. From Advanced > IPMI > LAN Settings, press enter.
3. Configure the iRMC card.
a. Disable DHCP.
b. Set the LAN port to separate.
c. Enter the IP data for the iRMC card.
4. On the Advanced screen, select Power On/Off, press Enter.
5. Check that the values are as follows:
a. Software: Enabled
b. Power Button: Enabled
c. Power-On Source: Bios controlled.
d. Remote: Enabled
e. LAN: Enabled
f. Wake up Timer: Disabled
g. Wake up Mode: Daily
Supported network topologies

Plan the network interfaces that will be used by the Telephony Application Servers
and the IBM WebSphere Application Servers within an IBM Lotus Sametime
Unified Telephony deployment.
If the Telephony Application Server/WebSphere Application Server nodes will be

used for purposes other than providing telephony services (for example, network
security or device management), you may need to use an additional network
interface on some or all nodes in the cluster. The additional adapters will not be
defined in the Lotus Sametime Unified Telephony automation policy, so they will
be completely outside the control of SAMP. However, this additional network
interface must be on a different subnet from the subnet used by Telephony
Application Server and WebSphere Application Server signaling interfaces.
Example 1
v Signaling for Telephony Application Server/WebSphere Application Server
nodes will be on the bond0 interface. The bond0 interface is assigned to subnet
A.
v A management LAN will be on the bond1 interface. The bond1 interface is
assigned to subnet B, to keep it separate from the bond0 interface.
Example 2
v Signaling for the Telephony Application Server nodes will be on the bond0
interface. The bond0 interface assigned to subnet A.
v Signaling for the WebSphere Application Server nodes will be on the bond1
interface. The bond1 interface is also assigned to subnet A. Because bond0 and
bond1 are both used for signaling, they can reside on the same subnet.
v A management LAN will be on the bond2 interface. The bond2 interface is
assigned to subnet B, because it must be hosted on a separate subnet from the
signaling interfaces.
The reason for this requirement is that it is not possible to have static configured
network interfaces in the same IP subnet as the Telephony Application
Server/WebSphere Application Server signaling subnet. Each IP address will
require an entry in the kernel routing table. In the case of an interface in the same
subnet as the TAS/WAS signaling subnet, there will be 2 routes for the same
subnet. If the interface that created the second entry (in our examples, for the
management LAN) fails, the communication for this subnet will break down –
even if there is another interface that still is able to communicate. As a result
SAMP will incorrectly recognize the Telephony Application Server/WebSphere
Application Server interface as broken and initiate a failover to the standby node.
Keeping the signaling interfaces on a separate subnet prevents this problem.
Network considerations
When setting up a SAMP cluster, it is important to understand that all peer nodes
must have the same network interface configuration; in particular:
v If Telephony Application Server/WebSphere Application Server signaling will be
on bond0, then all nodes in the cluster must have a bond0 interface.
v If Telephony Application Server signaling will be on bond0 and WebSphere
Application Server signaling on bond1, then all nodes in the cluster must have a
bond0 interface and a bond1 interface.
v If an extra interface is required (for example, for network security purposes), this
interface must be on a separate subnet from the subnet used by Telephony
Application Server and WebSphere Application Server.
Bonding adaptors
The SUT cluster of TAS and Media Server systems are intended to be highly
available. The cluster is installed on top of cluster-failover software, called Tivoli
System Automation for Multiplatforms which is covered in detail in the Installation
of TAS Software section. With reliability in mind, it is necessary to add redundancy
to network ports in a TAS machine. In a failover configuration, a bond interface
(bond0) using two ethernet interfaces (eth0 and eth1) must be created.
About this task
In a failover configuration a TAS machine must have:

v Two ethernet interfaces if TAS and WebSphere Application Server reside on the
same NIC
v Four ethernet interfaces if TAS and WebSphere Application Server reside on
separate NICs
v All ethernet interfaces must be on the same subnet
To decrease the likelihood of a failover condition due to a network switch, adapter,

or cable failure, bonding adapters can be used to team two or more adapters.
Procedure
1. To configure bonding adapters for SUT on SLES 10 SP3, modify the ifcfg scripts
in the /etc/sysconfig/network directory. By default, there is at least one file in
the form of ifcfg-eth-id-mac_address format. Example:

Default Network Configuration File Names
tasnode1:/etc/sysconfig/network # ls -al ifcfg-eth*
-rw-r--r-- 1 root root 211 May 17 09:00 ifcfg-eth-id-00:1a:64:62:47:d2
-rw-r--r-- 1 root root 211 May 17 09:00 ifcfg-eth-id-00:1a:64:62:47:d3
2. To simplify the configuration, rename the ifcfg-eth-id-<mac_address> file to a
format that matches the interface name. To determine the appropriate name:
execute ifconfig -a use the output to correlate the interface name to the mac
address (HWaddr). Example output from ifconfig -a. Rename
ifcfg-eth-id-00:1a:64:62:47:d2 to ifcfg-eth0, and ifcfg-eth-id-
00:1a:64:62:47:d3 to ifcfg-eth1.
Network Interface List
tasnode1:/etc/sysconfig/network # ifconfig -a | more
eth0 Link encap:Ethernet HWaddr 00:1F:34:12:57:E2
inet addr:19.142.227.17 Bcast:19.142.227.255 Mask:255.255.252.0
inet6 addr: fe80::21a:64ff:fe62:47d2/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:14532939 errors:0 dropped:0 overruns:0 frame:0
TX packets:127637196 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:2175565080 (2074.7 Mb) TX bytes:655615846 (625.2 Mb)
Interrupt:90
eth1 Link encap:Ethernet HWaddr 00:1A:64:62:47:D3

BROADCAST MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:0 (0.0 b) TX bytes:0 (0.0 b)
Interrupt:98
3. Modify the ifcfg-eth files as appropriate for bonding. The original
configuration of ifcfg-eth0 looks like this example:
Default ifcfg File (ifcfg-eth0)
BROADCAST=’’
ETHTOOL_OPTIONS=’’
MTU=’’
NAME=’’
NETWORK=’’
STARTMODE=’onboot’
UNIQUE=’rBUF.OxfKyHLVUp6’
USERCONTROL=’no’
_nm_name=’bus-pci-0000:02:01.0’
BOOTPROTO=static
IPADDR=19.142.227.17
NETMASK=255.255.252.0
4. For an adapter to function as a bonding slave, the configuration file must be
modified. Specifically, the STARTMODE, BOOTPROTO, IPADDR, NETMASK,
MASTER, and SLAVE properties. Make the following changes to both
ifcfg-eth0 and ifcfg-eth1:
a. Set STARTMODE to Off.
b. Set BOOTPROTO to None.
c. Remove IPADDR.
d. Remove NETMASK.
e. Add MASTER='bond0'.
f. Add SLAVE='yes'.
5. Create the bonding interface and associating the physical adapters as slaves.
Create a file called ifcfg-bond0. The example which follows can be copied as is,
with the following exceptions:
a. Update IPADDR and NETMASK as appropriate.
b. Include BONDING_SLAVEx for each physical adapter to be included in the
bond pair.
c. Execute service network restart to activate the configuration. With the steps
completed, network connectivity is not interrupted if either of the networks
independently fail.
Bonding Adapter (ifcfg-bond0)
BONDING_MASTER=’yes’
BONDING_MODULE_OPTS=’mode=1 miimon=100 primary=eth0’
BOOTPROTO=’static’
BROADCAST=’’
ETHTOOL_OPTIONS=’’
IPADDR=’19.142.227.17’
MTU=’’
NAME=’’
NETMASK=’255.255.252.0’
NETWORK=’’
REMOTE_IPADDR=’’
STARTMODE=’auto’
USERCONTROL=’no’
BONDING_SLAVE0=’eth0’
BONDING_SLAVE1=’eth1’
RAID unit setup

During the installation of the TAS hardware, you must configure the SCSI RAID
and create a disk mirror.
Before you begin
You must have setup the BIOS.
About this task
You must configure the SCSI RAID unit and create a disk mirror as follows:
Procedure
1. Turn on the server. A number of screens display the system information until
an LSI banner displays and indicates that the LSI controller is initializing.
LSI Logic Corp. MPT SAS BIOS
MPTBIOS-6.12.00.00 (2006.10.31)
Copyright 2000-2006 LSI Logic Corp.
Initializing ............
2. After initialization is complete, the system displays the following message:
LSI Logic Corp. MPT SAS BIOS
MPTBIOS-6.12.00.00 (2006.10.31)
Copyright 2000-2006 LSI Logic Corp.
Press Ctrl-C to start LSI Logic Configuration Utility...
3. Press CTRL+C. The LSI Logic Utility Screen displays.
4. Press Enter to select the internal controller (SAS1068)
5. Press the Down Arrow Key to select RAID properties. Press Enter.
6. Select Create IM Volume and press Enter to create the array.
7. Use the Right Arrow Key to select the RAID Disk in the Slot Num 0.
8. Press the + (plus sign) key to select the drive to be placed in the array.
9. Press the D key to overwrite all existing data and create an IM array. The first
drive is now selected.
10. Use the Down Arrow Key to select the RAID Disk in Slot Num 1.

11. Press the + (plus key) to select the second drive of the array and press the C
key to create the array.
12. Create and save the new array at the system prompt.
13. Use the Down Arrow Key to select the Save changes option then exit this
menu and press enter.
14. The system processes the request which can take up to a minute.
15. Press the Esc key to exit the Adapter Properties menu. The Adapter List
Global Properties is displayed. Press the Esc key to exit this screen.
16. Select the Exit the Configuration Utility and Reboot option and press Enter
to finish the RAID configuration. After the system reboots, the system displays
a screen that indicates the single logical volume has been created.
Start up the remote console

You can start up the remote console through a web Browser.
Before you begin
Set up the BIOS and RAID array for the TAS.
About this task
Using the web browser, log on to the Remote Console. Test the console using the
Video Redirection.
Procedure
1. Log on to the Remote Console through a web browser using the IP address
you entered within the BIOS for the LAN settings.
2. Accept any certificate warnings that appear, enter the user name, and password
as follows: USERID/PASSW0RD (the 0 is a zero.)
3. The Server Management Information screen appears. Select Server
Management, then Video Redirection in the navigation list on the left side.
4. Start the Video Redirection using the button.
5. Accept all the certificate warnings that appear and all other messages by
clicking OK.
6. At the end, a similar screen appears that reflect the console messages.
7. To finish, select Exit from the Extra drop down menu and click Ok.
SAN deployment
The following document focuses on the setup of a SAN (Storage Area Network)
system — IBM DS3400. The document also describes an example environment of
multiple TAS systems with a single standby/failover server. A SAN is a hard
requirement for this environment.
Acronyms/Terminology:
v FC: Fiber Channel: A gigabit speed network technology used to access storage
networking. Can be either twisted pair or fiber-optic
v SAN: Storage Area Network. A disk array that is accessed with an FC
v HBA: Host Bus Adapter. The PCI card installed in the host to access the SAN or
SAN switch with an FC
v Array: Set of disk drives logically grouped and associated to a RAID level
v Logical Drive: Virtual component created for the host to access an allocated
portion of the disk array
v LUN: Logical Unit Number. The logical drive identifier as it is known to the
accessing host
Hardware:
The hardware components relevant to this setup focus on the TAS and SAN
portion of the topology, with no details of the Sametime Server or TCS. These
components remain unchanged and are independent of a TAS and SAN. The
following table includes the hardware components and reference host names for
examples used through the document.
Component Type/Model Type/Model

TAS 1 IBM xSeries 3455 stx3455d
TAS 2 IBM xSeries 3455 stx3455e
TAS 3 IBM xSeries 3455 stx3455f
TAS 4 IBM xSeries 3455 stx3455g
TAS 5 IBM xSeries 3455 stx3455h
SAN Disk System IBM DS3400 N/A
24 Port SAN Switch IBM SAN 24B-4 N/A
Architecture Overview
Logical Mappings
The following diagram details the overall architecture of Sametime Unified

Telephony in a failover environment. HBA cards are installed on all TAS systems,
including the standby systems. The TAS systems are then in a position to connect
to the SAN with a SAN switch.
Note: The cluster software, SAMP, is not included in this diagram. Full
deployment descriptions, including how the cluster software interacts with the
topology, are provided in subsequent sections. The main purpose of this section is
to explain how the SAN is used.

Configuring SAN LUNs:
The following diagram provides an example logical mapping of hosts/partitionsto

SAN LUNs. The SAN is broken up into logical disk arrays which the HBA (host
bus adapter) cards on the TAS servers access with standard SATA drive mappings,
for example, sda and sdb. The table provides an example host-to-LUN mapping,
along with their associated array allocations. For example, the TAS residing on
stx3455b mounts the /enterprise directory with the SATA drive sdb, which maps
to LUN 0 on the SAN.
The active and standby TAS systems interact with the SAN LUNs in the following
manner:
By providing the logical mappings to each system, the standby can take over from
any system in the cluster.
Note: All systems maintain all logical mappings. If the standby takes over from a
failed system, once the failed system has been repaired, for example with an OS
patch, the original active node becomes the acting standby node.

The SAN is configured using a utility called Storage Manager — a simple interface
for configuring arrays and logical drives. Use the Storage Manager utility to create
new logical drives, name logical drives, and view the logical drive name to LUN
mapping. For simplicity, the SAN can be configured with a host group that
contains all TAS servers enabling all TAS servers access to all LUNs. With this
configuration, mount the appropriate LUN from the appropriate machine. The
diagram provides an example array allocation, including the relevant Host Group:
Installing the QLogic HBA (Host Bus Adapter)

These instructions cover installing the Qlogic 4 Gb FC single-port PCIe HBA for
SystemX adapters in an IBM Lotus Sametime Unified Telephony deployment.
Procedure
1. Install the HBA card into an empty PCI slot on the Telephony Application
Server.
2. Update the system to the latest RPMs.
3. Ensure that the active kernel is a valid non-debug kernel and that the driver
installation hangs:
a. SLES 10 SP3 kernel used: 2.6.16.54-0.2.8-bigsmp.
b. Validate using the uname -a command.
c. Switch the kernel by updating the "default" integer in /boot/grub/menu.lst
(second line) and reboot.
4. Download the latest QLogic driver:
a. Browse to http://www.qlogic.com.
b. Click the Downloads tab.
c. Under "QLogic Models" click operating system in the search box.
d. Select Fibre Channel Adapters > Linux > Linux Novell SLES (32-bit).
e. Click the Go button to run the search.
f. On the results page, look in the "Drivers" table, then locate the section for
the "2.6 Kernel Drivers" and click the link for SANsurfer Linux Driver
Installer (x86/x64/IA64) to begin the download.
The SANsurfer installer includes the scli for performing operations with a CLI.
It also automates all the steps necessary to install, configure, and load the HBA
drivers upon reboot.
5. Extract qlafc-linux-8.02.*-install.tgz.
6. Change to the extract qlafc-linux-8.02.*-install directory.
7. Install the drivers using ./qlinstall.
8. Reboot the system.
Updating the QLogic HBA (Host Bus Adapter)

The level of the Qlogic HBA BIOS that is shipped with some systems does not
support UEFI (such as V1.28). Update the HBA BIOS to support UEFI, and shorten
start-up time.
About this task
Download both the SANSurfer application and the Multi-boot image, and then use
SANSurfer to install the image.

In this task, you will update the HBA BIOS to the following versions:
v 4GB BIOS version: 2.02
v 4GB FCode version: 2.00
v 4GB EFI version: 2.00
v Firmware version: 4.03.01
Procedure
1. Download the Qlogic Multi-boot Image for 4GB FC adapters:
a. Browse to http://driverdownloads.qlogic.com/
QLogicDriverDownloads_UI/ShowEula.aspx?resourceid=25334
&Contentid=69579&docid=21253.
b. Click the Agree button at the bottom of the page.
c. In the "File Download" dialog box, click Save.
d. In the "Save As" box, select a directory for storing the file, and click Save.
e. Extract the Multi-boot Image.
This step extracts several files, so you may want to extract them to a
subdirectory.
2. Download the Qlogic SANSurfer Management Application for Linux:
a. Browse to http://driverdownloads.qlogic.com/
QLogicDriverDownloads_UI/ShowEula.aspx?resourceid=24816
&Contentid=67882&docid=19583.
b. Click the Agree button at the bottom of the page.
c. In the "File Download" dialog box, click Save.
d. In the "Save As" box, select a directory for storing the file, and click Save.
e. Extract the SANSurfer Management Application.
f. Run the extracted file to install the SANSurfer Management Application.
g. On the "Choose a product" screen, click FC HBA GUI and ALL Agent.
3. After the SANSurfer application has installed, start it.
4. In the "Enter Hostname or IP Address" box, select Local Host from the list,
and then click the Connect button.
5. When prompted to start a General Configuration Wizard, click No.

6. On the left side of the SANSurfer screen, wait for the "FC HBA" tab to
populate, and then select your one of your HBA ports.
7. Click the Utilities tab, and then click Update Entire Image.

8. In the "Open" box, browse to the directory where you extracted the Multi-boot
image (Step 1), select the Q24AF169.BIN, and then click Open.
9. When prompted, type the security password for the HBA Adapter Bios, click
OK to continue, and wait for the update to complete.
The default password is "config" (contact your technical support if the
password has been changed).
10. When the "Flash Update Complete" message appears, click OK.
Configuring the QLogic HBA

These instructions cover configuring the Qlogic 4 Gb FC single-port PCIe HBA for
SystemX adapters
Procedure
1. Start SuSE Linux from the system's internal RAID.

When using X3550 M2 servers that are connected to a SAN via Qlogic adapters,
you may not be able to start SuSE Linux from the system's internal RAID. If
this happens, enable "Legacy only" under boot manager in UEFI using the
following boot priority:
v CD/DVD Legacy only
v Hard disk 0
v Hard disk 1
Now you can start SuSE Linux from the RAID.
2. View the SCSI configuration and browse the SAN LUNs available using cat
/proc/scsi/scsi. In this example, the SAN LUNs are accessible with scsi5.
SCSI Devices
tasnode1:~ # cat /proc/scsi/scsi
Attached devices:
Host: scsi4 Channel: 00 Id: 00 Lun: 00
Vendor: IBM-ESXS Model: ST373455SS Rev: BA26
Type: Direct-Access ANSI SCSI revision: 05
Vendor: IBM-ESXS Model: ST373455SS Rev: BA26
Vendor: LSILOGIC Model: Logical Volume Rev: 3000
Vendor: IBM Model: 1722-600 Rev: 0914
Vendor: IBM Model: Universal Xport Rev: 0914
Vendor: AVOCENT Model: vmDisk-CD Rev: 0.01
Type: CD-ROM ANSI SCSI revision: 02
Vendor: AVOCENT Model: vmDisk Rev: 0.01
tasnode1:~ #
3. Determine the SATA drive ID by browsing the /sys/bus/scsi/devices directory
and look for the block identifier block:sdX. In the example, the SAN is scsi5, so
the device identifiers that begin with 5 were browsed. The last integer in each
device directory is the LUN identifier that corresponds to the SAN
configuration. If 5:0:0:0 (LUN 0), the SATA drive is /dev/sdb block:sdb. Use
this information to determine how to mount the SAN drives on a given system.
Determine SD Identifiers
tasnode1:~ # cd /sys/bus/scsi/devices/
tasnode1:/sys/bus/scsi/devices # ls
4:0:0:0 4:0:1:0 4:1:0:0 5:0:0:0 5:0:0:1 5:0:0:2 5:0:0:3
5:0:0:31 5:0:0:4 5:0:0:5 6:0:0:0 7:0:0:0
tasnode1:/sys/bus/scsi/devices # ls 5\:0\:0\:0
block:sdb delete driver iocounterbits ioerr_cnt
model queue_depth rescan rev scsi_disk:5:0:0:0
scsi_level timeout uevent
bus device_blocked generic iodone_cnt iorequest_cnt
power queue_type retries scsi_device:5:0:0:0 scsi_generic:sg3
state type vendor
block:sdc delete driver iocounterbits ioerr_cnt
state type vendor
block:sdd delete driver iocounterbits ioerr_cnt
state type vendor
block:sde delete driver iocounterbits ioerr_cnt
state type vendor
block:sdf delete driver iocounterbits ioerr_cnt
state type vendor
block:sdg delete driver iocounterbits ioerr_cnt
state type vendor
tasnode1:/sys/bus/scsi/devices #
4. Create an ext3 file system for each SATA drive using mke2fs -j /dev/sdb.
Substitute /dev/sdb with the information determined from step 2. Repeat for
each drive.
5. Determine the disk identifier to use in the /etc/fstab file for mounting by
browsing /dev/disk/by-id. In the example, scsi-
3600a0b80000f14a900000368489ae610 is the disk identifier for /dev/sdb.
tasnode1:~ # cd /dev/disk/by-id/
tasnode1:/dev/disk/by-id # ls -al
total 0
drwxr-xr-x 2 root root 320 Aug 7 15:03 .
drwxr-xr-x 5 root root 100 Aug 7 11:03 ..
lrwxrwxrwx 1 root root 9 Aug 7 11:03 edd-int13_dev80 -> ../../sda
lrwxrwxrwx 1 root root 10 Aug 7 11:03 edd-int13_dev80-part1 -> ../../sda1
lrwxrwxrwx 1 root root 10 Aug 7 11:03 edd-int13_dev80-part2 -> ../../sda2
lrwxrwxrwx 1 root root 9 Aug 7 11:03
scsi-3600508e00000000046b9ebfdf84b9a0a -> ../../sda
scsi-3600508e00000000046b9ebfdf84b9a0a-part1 -> ../../sda1
scsi-3600508e00000000046b9ebfdf84b9a0a-part2 -> ../../sda2
scsi-3600a0b80000f14a900000368489ae610 -> ../../sdb

scsi-3600a0b80000f14a900000373489ae660 -> ../../sdd
scsi-3600a0b80000f14a90000037e489ae6a6 -> ../../sdf
scsi-3600a0b80000f4d2e0000019d489ad2f1 -> ../../sdc
scsi-3600a0b80000f4d2e000001a3489ad333 -> ../../sde
scsi-3600a0b80000f4d2e000001a9489ad387 -> ../../sdg
usb-AVOCENT_vmDisk-CD_00430009CB6 -> ../../sr0
usb-AVOCENT_vmDisk_00430009CB6 -> ../../sdh
tasnode1:/dev/disk/by-id #
Disk Identifiers
6. Create fstab entries for each mount point on the file system using the disk
identifier from step 4. Specifically, create entries for /enterprise and
/opt/IBM/WebSphere.
/etc/fstab Configuration
tasnode1:~ # cat /etc/fstab
/dev/disk/by-id/scsi-3600508e00000000046b9ebfdf84b9a0a-part2 /
ext3 acl,user_xattr 1 1
proc /proc proc defaults
0 0
sysfs /sys sysfs noauto
0 0
debugfs /sys/kernel/debug debugfs noauto
0 0
usbfs /proc/bus/usb usbfs noauto
0 0
devpts /dev/pts devpts mode=0620,gid=5
0 0
/dev/sda1 swap swap defaults 0 0
/dev/disk/by-id/scsi-3600a0b80000f14a900000368489ae610 /enterprise
ext3 noauto,acl,user_xattr 1 0
/dev/disk/by-id/scsi-3600a0b80000f4d2e0000019d489ad2f1 /opt/IBM
tasnode1:~ #
7. Test the mounts by executing mount /enterprise
Configuring for MPIO (Multipath IO)

Configure Linux to support Multipath IO connectivity with the SAN in an IBM
Lotus Sametime Unified Telephony deployment.
About this task
The example used in this topic is a 3550 M2 with a dual port Qlogic card. Both
ports are connected to two different Dell EMC SAN switches. Two LUNs are
configured on the SAN and assigned to the Qlogic WWNs.
Procedure
1. Log in to the server as root.
2. Show SCSI devices:
geatas1node2:~ # lsscsi
[0:0:0:0] cd/dvd TSSTcorp CDDVDW TS-L633B IB03 /dev/sr0
[4:0:0:0] disk IBM-ESXS ST9146803SS B536 -
[4:0:1:0] disk IBM-ESXS ST9146803SS B536 -
[4:1:1:0] disk LSILOGIC Logical Volume 3000 /dev/sda
[5:0:0:0] disk DGC RAID 5 0428 /dev/sdb
[5:0:0:1] disk DGC RAID 5 0428 /dev/sdc
[5:0:1:0] disk DGC RAID 5 0428 /dev/sdd
[5:0:1:1] disk DGC RAID 5 0428 /dev/sde
[6:0:0:0] disk DGC RAID 5 0428 /dev/sdf
[6:0:0:1] disk DGC RAID 5 0428 /dev/sdg
[6:0:1:0] disk DGC RAID 5 0428 /dev/sdh
[6:0:1:1] disk DGC RAID 5 0428 /dev/sdi
Two LUNs are created and visible. LUN 0 is indicated by "0" as the last digit:
[5:0:0:0]
[5:0:1:0]
[6:0:0:0]
[6:0:1:0]
while LUN 1 is indicated by "1" as the last digit:
[5:0:0:1]
[5:0:1:1]
[6:0:0:1]
[6:0:1:1]
3. Add the multipath package using yast.
4. Insert the multipath drivers into the boot sequence:
geatas1node2:~ # insserv multipathdgeatas1node2:~ # insserv boot.multipath
5. Start the drivers:
geatas1node2:~ # /etc/init.d/boot.multipath start
Creating multipath targets done

geatas1node2:~ multipathd start
Starting multipathd done
6. Start the Multipath daemon in command mode:
geatas1node2:~ # multipathd –k
7. Show available commands:
multipathd> help
multipath-tools v0.4.8 (08/02, 2007)
CLI commands reference:
list|show paths
list|show maps|multipaths
list|show maps|multipaths status
list|show maps|multipaths stats
list|show maps|multipaths topology
list|show topology
list|show map|multipath $map topology
list|show config
list|show blacklist
list|show devices
add path $path
remove|del path $path
add map|multipath $map
remove|del map|multipath $map
switch|switchgroup map|multipath $map group $group
reconfigure
suspend map|multipath $map
resume map|multipath $map
reinstate path $path
fail path $path
8. Display the generated multipath topology:
multipathd> show top
36006016001802200b593f40ae042df11 dm-0 DGC,RAID 5
[size=30G][features=1 queue_if_no_path][hwhandler=1 emc]
\_ round-robin 0 [prio=2][active]
\_ 6:0:0:1 sdg 8:96 [active][ready]
\_ 5:0:0:1 sdc 8:32 [active][ready]
\_ round-robin 0 [prio=0][enabled]
\_ 6:0:1:1 sdi 8:128 [active][ready]
\_ 5:0:1:1 sde 8:64 [active][ready]

36006016001802200b493f40ae042df11 dm-1 DGC,RAID 5
[size=30G][features=1 queue_if_no_path][hwhandler=1 emc]
\_ round-robin 0 [prio=2][active]
\_ 6:0:0:0 sdf 8:80 [active][ready]
\_ 5:0:0:0 sdb 8:16 [active][ready]
\_ round-robin 0 [prio=0][enabled]
\_ 6:0:1:0 sdh 8:112 [active][ready]
\_ 5:0:1:0 sdd 8:48 [active][ready]
multipathd> geatas1node2:~ #
geatas1node2:~ #
9. Display disks:
geatas1node2:~ # cd /dev/disk/by-id
geatas1node2:/dev/disk # ls
edd-int13_dev80
edd-int13_dev80-part1
scsi-3600508e000000000a8648159e62e3106
scsi-3600508e000000000a8648159e62e3106-part1
scsi-3600508e000000000a8648159e62e3106-part2
scsi-36006016001802200b493f40ae042df11
scsi-36006016001802200b593f40ae042df11
10. Create File systems:
geatas1node2:/dev/disk # mkfs -j /dev/disk/by-id/scsi-6006016001802200b493f40ae0
mke2fs 1.38 (30-Jun-2005)

Filesystem label=
OS type: Linux
Block size=4096 (log=2)
Fragment size=4096 (log=2)
3932160 inodes, 7864320 blocks
393216 blocks (5.00%) reserved for the super user
First data block=0
Maximum filesystem blocks=8388608
240 block groups
32768 blocks per group, 32768 fragments per group
16384 inodes per group
Superblock backups stored on blocks:
32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208,
4096000
Writing inode tables done

Creating journal (32768 blocks): done
Writing superblocks and filesystem accounting information: done
This filesystem will be automatically checked every 36 mounts or

180 days, whichever comes first. Use tune2fs -c or -i to override.
geatas1node2:/dev/disk # mkfs -j /dev/disk/by-id/scsi-6006016001802200b593f40ae0
mke2fs 1.38 (30-Jun-2005)

Filesystem label=
OS type: Linux
Block size=4096 (log=2)
Fragment size=4096 (log=2)
3932160 inodes, 7864320 blocks
393216 blocks (5.00%) reserved for the super user
First data block=0
Maximum filesystem blocks=8388608
240 block groups
32768 blocks per group, 32768 fragments per group
16384 inodes per group
Superblock backups stored on blocks:
32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208,
4096000
Writing inode tables: done
Creating journal (32768 blocks): done
Writing superblocks and filesystem accounting information: done
This filesystem will be automatically checked every 31 mounts or

180 days, whichever comes first. Use tune2fs -c or -i to override.
geatas1node2:/dev/disk #
11. Create Libraries:
geatas1node2:/dev/disk # cd /
geatas1node2:/ # mkdir /enterprise
geatas1node2:/ # cd /opt/
[mgeatas1node2:/opt # mkdir IBM
geatas1node2:/opt # cd IBM/
geatas1node2:/opt/IBM # mkdir WebSphere
12. Display disks for mounting:
geatas1node2:~ # mount /dev/disk/by-id/
edd-int13_dev80
scsi-3600508e000000000a8648159e62e3106
scsi-3600508e000000000a8648159e62e3106-part1
scsi-3600508e000000000a8648159e62e3106-part2
scsi-36006016001802200b493f40ae042df11
scsi-36006016001802200b593f40ae042df11
13. Mount disks
geatas1node2:~ # mount /dev/disk/by-id/scsi-36006016001802200b493f40ae042df11 /enterprise/
geatas1node2:~ # mount /dev/disk/by-id/scsi-36006016001802200b593f40ae042df11 /opt/IBM/WebSphere/

14. Display mounted disks:
geatas1node2:~ # mount
/dev/sda2 on / type reiserfs (rw,acl,user_xattr)
proc on /proc type proc (rw)
sysfs on /sys type sysfs (rw)
debugfs on /sys/kernel/debug type debugfs (rw)
udev on /dev type tmpfs (rw)
devpts on /dev/pts type devpts (rw,mode=0620,gid=5)
securityfs on /sys/kernel/security type securityfs (rw)
/dev/dm-1 on /enterprise type ext3 (rw)
/dev/dm-0 on /opt/IBM/WebSphere type ext3 (rw)
The mounts are displayed with their new virtual names: dm-0 and dm-1
15. Display the files ystems:
geatas1node2:~ # df
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/sda2 140468028 13868796 126599232 10% /
udev 3103544 180 3103364 1% /dev
/dev/dm-1 30963708 176288 29214556 1% /enterprise
/dev/dm-0 30963708 176288 29214556 1% /opt/IBM/WebSphere
geatas1node2:~ #
16. Revert to normal Failover configuration for further configuration.
Software installation
Review the installation checklist, and then install TCS and TAS.
Installing Telephony Control Server

This section provides information about installing the Telephony Control Server.

Downloading the Telephony Control Server installation package
Download and extract the IBM Lotus Sametime Unified Telephony installation
package for the Telephony Control Server.
About this task
The Telephony Control Server is packaged with the Linux operating system; the
combined package is referred to as the "Connect Server" in the Download
document.
Procedure
v DVD: Insert the DVD of for the Telephony Control Server into the DVD
drive, and mount it.
v Download: Download the Sametime Unified Telephony Connect Server
package to a temporary location.
– See the SametimeUnified Telephony 8.5.1 download document for details
on part numbers and assemblies.
– For information on downloading packages from IBM Passport Advantage®
website, see Using Passport Advantage to download IBM products.
2. Create a directory called /software/IBM by running the following command:
mkdir /software/IBM
3. Copy the package to the new /software/IBM directory:
For DVD, use the following command:
cp /DVD_mount_point/file_name.tgz /software/IBM
4. Now navigate to the new directory:
cd /software/IBM
5. Finally, extract the appropriate installer with the following command:
tar xvfz file_name.tgz
Using Passport Advantage to download IBM products:
IBM Passport Advantage website provides access to all of your entitled software;
you can download products directly to your computer for installation, and
download the Quick Start Guide for information how to get started installing IBM
Lotus Sametime.
Before you begin

1. Review the Sametime Detailed System Requirements to ensure that your
systems are prepared for installation.
2. Use the Download document to determine product part numbers; these are the
items you will download from Passport Advantage.
About this task
Passport Advantage provides access to your IBM software purchases, so you can
download products directly to the computers where you want to install them. For
information on the Passport Advantage program, review the program overview.
Downloading products from Passport Advantage requires an IBM customer ID; if

you do not have one, you must register with the site:
1. Open a browser and navigate to Passport Advantage sign-in page.
2. Complete the new customer registration form.
3. Click Register.
When you receive your IBM customer ID, proceed to download products as
explained below.
Procedure
1. Open a browser and navigate to the Passport Advantage sign-in page.
2. Click Customer sign in
3. Enter your IBM customer ID and password, and then click Sign in.
4. On the "Software and services online" page, click Software download &
media access.
5. On the "Find downloads & media" page, click Download finder.
Passport Advantage displays list of your entitled downloads (products that

you have purchased).
6. Click a product to select it, and then click Continue to search for its
downloadable packages.

Tip: If you know a download package's part number (specified in the
Download document for each product), you can search on that part number to
quickly find the downloadable package.
Software products are posted "assemblies" containing different versions of the
product for use with various operating systems and languages. Packaging
varies depending on the size and complexity of each product.
7. Under "Select criteria", select a language and platform (operating system) for
the product you want to download.
8. Under " Download options", select Yes for the option "If available, would you
like to see associated products at no additional charge?".
This ensures that you can view and download optional products that are used
with the primary product (for example, an LDAP directory server where you
can store user names).
9. Click Continue.
Passport Advantage displays the list of assemblies (packages) for the selected
criteria.
10. Select your download:
v Select an assembly to download all of its included packages:
v Click the + to expand the assembly so you can select individual packages:
Important: You should always download a copy of the product's Quick Start
Guide because it provides an overview of the product installation as well as
links to additional documentation.
11. Select items to download and scroll to the bottom of the page.
12. Review the license agreement, and click I agree.
13. Click Download and select a location on your computer to store the
downloaded files.
What to do next
Review the Quick Start Guide for an installation overview as well as links to the
product documentation, where you will find instructions on installing the product.

Preparing for the node.cfg file use during installation
Create the node.cfg file that will be used for installing a Telephony Control Server
in an IBM Lotus Sametime Unified Telephony deployment.
Before you begin
To prepare for the installation of the Telephony Control Server you do not need
access to the server hardware. The node.cfg file is a settings file carrying all the
site-specific information needed to conduct an unassisted installation. To create the
file, you need the following materials and information:
v The NCPE (Node Configuration Parameters Editor) wizard. This is a .iso image
file, which can be burned to a CD for use in Microsoft Windows or Linux.
v Two USB flash drives. You will store a copy of the node.cfg on each, for use
when installing the two Telephony Control Server nodes.
v The 27 IP addresses required for the installation of the two Telephony Control
Server nodes.
v The gateway, DNS, and NTP addresses.
v The number of subnets to be used in the Lotus Sametime Unified Telephony
deployment (for example, will there be separate signaling, billing, and
management networks?), and whether the subnets exist on separate vLAN's.
Note: It is possible to run only two subnets; the wizard displays a warning but
you can ignore it.
About this task
You will perform the Telephony Control Server installation using a reference image
DVD, which contains default system configuration data (for example, operating
system parameters, Unix accounts, IP parameters for the node.cfg, and RTP
parameters), and the install scripts. When you create the node.cfg file, you specify
the actual parameters for your deployment. During installation of the Telephony
Control Server, the settings in the node.cfg file will override the default values
stored on the reference image. Two copies of the reference image DVD are
delivered, allowing you to run the installation simultaneously on the two
Telephony Control Server nodes.
Procedure
1. Burn the NCPE wizard .iso file to a CD as a disk image.
2. Start the NCPE wizard from the disk:
v Linux
Open a terminal (for example, xTerm) and navigate to the CD drive.
Depending on the version of Linux, check the permissions of the fies stored
in /mnt/cdrom or /media/cdrom (specifically, check the file
cdrom/ncpe/bin/ncpe. If this file is not executable, then you must copy the
entire NCPE directory onto the local file system, where you can change the
permissions using the following command:
#chmod 700 ncpe_location/ncpe/bin/ncpe
v Windows
Open Windows Explorer and browse the CD. Double-click the RunIfGui.bat
to run it.
3. On the Installation Framework screen, select Install then click Next to begin the
wizard.
What to do next
Run the wizard as explained in the following two topics. When the wizard
finishes, you will have configured the node.cfg file for use when installing the
Telephony Control Server.
Using the NCPE wizard to generate the node.cfg file:
Run the NCPE wizard and specify configuration settings that will be stored in the
node.cfg file and applied to each Telephony Control Server during installation in
an IBM Lotus Sametime Unified Telephony deployment.
Before you begin
Start the NCPE wizard as explained in “Preparing for the node.cfg file use during
installation” on page 51.
Procedure
1. On the Configuration and Hardware (1/1) screen fill in at least the following
fields before clicking Next:
Option Description
Hardware Platform Select IBM x3550M2.
Configuration Select Standard Duplex.
Node Separation Select one of the following:
v none if geographic separation will not be
used for the Telephony Control Server.
v separate if the Telephony Control Server
nodes will be geographically separated.
Survival Authority Type the IP address of the Telephony
Application Server, or if there will be
multiple Telephony Application Servers, use
the IP address of one that is physically
co-located.

2. On the Cluster Installation (1/1) screen, type a descriptive name for the
cluster, and for each node, and then click Next.
This information is used by the call processing software, and may be used for
external communication. The cluster and node names are combined as
ClusterName-Node1Name-Node2Name to create the default name that shows up
when you connect to the cluster with the Telephony Control Server Assistant.
For example, if you provide the following names:
v Cluster Name: tcscluster
v Node 1 Name: tcsnode1
v Node 2 Name: tcsnode2
the cluster name appears as tcscluster-tcsnode1-tcsnode2.
3. On the IP Configuration (1/3) screen, type the IP address of the following the
subnets for administration, signaling, and billing.
By default the Telephony Control Server configures 3 separate subnets. If you
will not use separate subnets, then the netmask for each network should be
the same and it should be at least 64 bits (for example, 255.255.255.192).

4. On the IP Configuration (2/3) screen, provide the following information
before clicking Next:
v DNS Configuration section: type the IP addresses of up to 3 DNS servers in
the Name Server IP x fields.
v NTP Configuration section: type the fully qualified domain names of up to
2 NTP servers in the Server x fields.
5. On the IP Configuration (3/3) screen, provide the following information (do

not click Next):
Option Description
Default Router Node 1 Type the IP address of the default router for
node 1.
Domain Name Type the fully qualified domain name of the
default router for node 1.
Cluster Name This field displays the default cluster name,
created by combining the cluster and node
names that you provided in step 2. You can
optionally override this name by typing a
new name now.
6. Click the Expert Mode button (instead of Next).
Use Expert mode to configure the CSTA connection by specifying the IP
address of every CSTA server (ever Telephony Application Server node) that
connects to the Telephony Control Server.
7. On the Expert Mode screen, click IP Configuration (4/6) in the navigation
tree.
8. In the "CSTA Servers" section of the IP Configuration (4/6) screen, do the
following:
a. In the CSTA Server field, type the IP address of a Telephony Application
Server node.
b. Click the button to add another CSTA server.

c. Repeat until you have added all CSTA servers.
In case of a failover system, the use the physical IP addresses of the
Telephony Application Server primary node and all failover nodes (you do not
need to provide the virtual IP addresses).

9. Now return to the wizard by clicking the button at the top of the screen.
10. Back in the wizard, make sure the current screen is the IP Security (1/3)
screen.
11. In the IP Security (1/3) screen, type the IP address of the Telephony
Application Server in the "SNMP Servers" section's Address field, and then
click Next.
This enables the Telephony Application Server to receive alarms from the
12. In the IP Security (2/3) screen's "Billing Servers" section, type the IP address
of the Telephony Application Server deployed in the Billing network into the
Address field, and then click Next.
This is the IP address that you entered for the "Billing Network" section's
Subnet Node 1 field on the IP Configuration (1/3) screen in step 3.
13. On the IP Security (3/3) screen, leave the settings alone and click the Finish
button.
Results
The settings you configured in the wizard are written to the node.cfg file, which
will be used to override default settings when the Telephony Control Server nodes
are installed.

Conducting the actual installation
Follow these steps to install the software.
Before you begin
You should have the following:

v 2 DVD's of the TCS installer prepared
v 2 USB memory sticks
v A prepared node.cfg file created and validated in the NCPE tool.
Note: For a complete list of parts (with descriptions) included in the installation
package, see the Download document.
Procedure
1. Check the TCS machines:
a. Ensure that TCS is in power-down status and that it is available for a fresh
configuration.
b. Check the cabling and the required hardware configuration.
Note: The installation process will stall if the cluster interconnects are not in
place.
c. Ensure that a console is available for both nodes to monitor the installation
process.
2. Copy node.cfg onto two empty and separate FAT32-formated USB drives as
node.cfg.primary on USB 1 and as node.cfg.secondary on USB 2.
3. Insert the TCS software installation DVDs and power on the system to execute
the installation procedure.
4. Insert the appropriate USB drives when prompted. The installation takes
approximately 30 minutes. The installation causes several system reboots. The
installation is complete when the following message is displayed: – system was
started on mode1 node!. In this example, mode1 is the name of the node.
Patching the Telephony Control Server

Update the installed IBM Lotus Sametime Unified Telephony deployment's
Telephony Control Server software by installing patches.
Before you begin

v You must have installed the Telephony Control Server application.
v You must have access to the root user account and password.
v While the patches are being applied, it is important that all other configuration
and provisioning work be stopped, to avoid problems.
v To minimize the impact on call processing performance, apply the patches
during off-peak times. You do not have to stop the server; calls will continue to
be processed during the update.
About this task
When you install IBMLotusSametime Unified Telephony 8.5.1.2, you must apply
the following patches to the Telephony Control Server to bring it fully up to date:
v PS0010.E07
v PS0010.E08
You will install the patches individually and in sequence.
Procedure
1. On Telephony Control Server, download the appropriate patches to the
/software/patch/V5.00.01.ALL.11 directory on node 1 of the cluster:
For Lotus Sametime Unified Telephony 8.5.1.2, you need the following patches:
v V5.00.01.ALL.11_PS0010.E07.tar
v V5.00.01.ALL.11_PS0010.E08.tar
If you already downloaded the entire "Connect Server" package to node 1,
locate the patches now and copy both of them to the /software/patch/
V5.00.01.ALL.11 directory.
If you have not already downloaded the patches, do it now as explained in
“Downloading the Telephony Control Server installation package” on page 47
(be sure to store both patches in the /software/patch/V5.00.01.ALL.11
directory).
2. On the Telephony Application Server, add the Telephony Control Server to the
CMP (Common Management Portal) as explained in “Adding a Telephony
Control Server to the CMP” on page 143 (leave the CMP open for the next
step).
3. In the CMP, click Operation & Maintenance > Configuration & Monitoring >
System Status > Applications.
4. In the nodes list, click the arrow next to the Telephony Application Server, and
then click Software Activation.
5. Activate a patchset:
a. In the Software Activation dialog box, select the Telephony Control Server
node 1 as the Location.

b. In the list of patchsets that appears, select a patchset to apply, and click the
Activate button.
Note: The most recently applied patchset is flagged as Active. Remember

that patchsets must be applied in proper sequence.
In the list of patchsets, the Type column will flag the newly activated
patchset as Active.
6. Repeat step 5 for every patchset that requires activation.
7. When you have finished applying patchsets, click Close to close the Software
Activation dialog box.
Obtaining and applying licenses to the TCS cluster

For the TCS Server to operate properly, the necessary licenses must be obtained
and installed. The TCS licenses are locked to the MAC address of the eth0 network
interface card. To obtain the required licenses, the installer or administrator must
retrieve the MAC address of the eth0 interface of each node. Licenses are bound to
the node.
About this task
Request the licenses as soon as possible. Allow at least two days receive them.
Procedure
1. Log in to both nodes as ‘root' user and running the following command on
each: tcsnode:# ifconfig eth0 | grep HWaddr
2. When you have both MAC addresses for each TCS node, request license files
for both nodes from your Sametime Unified Telephony contact. You receive two
files, one for each node. The file names of these license files contain the MAC
address so you know which file belongs to which node.
3. When you receive the two license files you then must apply them to each TCS
node.
a. Open a scp (winSCP) session to each TCS node.
b. Change directory to: /opt/unisphere/srx3000/cla/import.
c. Copy the license file with the matching MAC address in its file name into
the TCS node which has that MAC address.
When the file is copied into the directory, the file is applied by the licensing
agent of that node and then removed from the directory. The licensing agent
checks the directory every 5 seconds, so the license file is applied and removed
from the directory within 5 seconds.
4. Verify that the licenses have been applied by opening CMP when it is
configured and navigate toTelephony Control Server > Maintenance > System
Information > Dashboard. Under the License Information TCS section, which
is at the bottom of the right column, you can see the number of licenses on
each machine. These licenses must be equal.
Installing Telephony Application Servers

Installing Telephony Application Servers for use with IBM Lotus Sametime Unified
Telephony involves installing a series of supporting products. Be sure to install all
the require products as described in this section.
About this task
Before you can install the Telephony Application Server, you must install SUSE
Linux Enterprise Server.
Then, when you install the Telephony Application Server software, the following
applications are bundled with the Telephony Application Server software, and will
also be installed on the server:
v Tivoli® System Automation for Multiplatforms
v Telephony Application Server Framework
v WebSphere® Application Server
v Tivoli Directory Integrator
v Assembly lines scripts
v SIP proxy/registrar
v Administration applications
v OSGi bundles
v Call History database tables

Downloading the Telephony Application Server installation
package
Download and extract the IBM Lotus Sametime Unified Telephony installation
package for the Telephony Application Server.
About this task
The Telephony Application Server is packaged with the Linux operating system;
the combined package is referred to as the "Call Server" in the Download
document.
Procedure
v DVD: Insert the DVD of for the Telephony Application Server into the DVD
drive, and mount it.
v Download: Download the Sametime Unified Telephony Call Server package
to a temporary location.
– See the Sametime Unified Telephony 8.5.1 Call Server download document
for details on part numbers and assemblies.
– For information on downloading packages from IBM Passport Advantage
website, see Using Passport Advantage to download IBM products.
2. Create a directory called /software/IBM by running the following command:
mkdir /software/IBM
3. Copy the package to the new /software/IBM directory:
For DVD, use the following command:
cp /DVD_mount_point/file_name.tgz /software/IBM
4. Now navigate to the new directory:
cd /software/IBM
5. Finally, extract the appropriate installer with the following command:
Using Passport Advantage to download IBM products:
IBM Passport Advantage website provides access to all of your entitled software;
you can download products directly to your computer for installation, and
download the Quick Start Guide for information how to get started installing IBM
Lotus Sametime.
Before you begin
1. Review the Sametime Detailed System Requirements to ensure that your
systems are prepared for installation.
2. Use the Download document to determine product part numbers; these are the
items you will download from Passport Advantage.
About this task
Passport Advantage provides access to your IBM software purchases, so you can
download products directly to the computers where you want to install them. For
information on the Passport Advantage program, review the program overview.
Downloading products from Passport Advantage requires an IBM customer ID; if

you do not have one, you must register with the site:
1. Open a browser and navigate to Passport Advantage sign-in page.
2. Complete the new customer registration form.
3. Click Register.
When you receive your IBM customer ID, proceed to download products as
explained below.
Procedure
1. Open a browser and navigate to the Passport Advantage sign-in page.
2. Click Customer sign in
3. Enter your IBM customer ID and password, and then click Sign in.
4. On the "Software and services online" page, click Software download &
media access.
5. On the "Find downloads & media" page, click Download finder.

Passport Advantage displays list of your entitled downloads (products that
you have purchased).
6. Click a product to select it, and then click Continue to search for its
downloadable packages.
Tip: If you know a download package's part number (specified in the

Download document for each product), you can search on that part number to
quickly find the downloadable package.
Software products are posted "assemblies" containing different versions of the
product for use with various operating systems and languages. Packaging
varies depending on the size and complexity of each product.
7. Under "Select criteria", select a language and platform (operating system) for
the product you want to download.
8. Under " Download options", select Yes for the option "If available, would you
like to see associated products at no additional charge?".
This ensures that you can view and download optional products that are used
with the primary product (for example, an LDAP directory server where you
can store user names).
9. Click Continue.
Passport Advantage displays the list of assemblies (packages) for the selected
criteria.
10. Select your download:
v Select an assembly to download all of its included packages:
v Click the + to expand the assembly so you can select individual packages:

Important: You should always download a copy of the product's Quick Start
Guide because it provides an overview of the product installation as well as
links to additional documentation.
11. Select items to download and scroll to the bottom of the page.
12. Review the license agreement, and click I agree.
13. Click Download and select a location on your computer to store the
downloaded files.
What to do next
Review the Quick Start Guide for an installation overview as well as links to the
product documentation, where you will find instructions on installing the product.
Installing SUSE Linux

This section describes the installation process for the SuSE Linux operating system.
Before you begin
If you already have Linux SUSE 10 installed on your server, you can skip this task;
however make sure that the following requirements are in place before you
continue to the next task:
v The graphical desktop can be either GNOME or KDE
v The default run level at boot should be 3 - full multi-user with network
v In the network settings, the option "Change host name via DHCP" should be
disabled.
If you have not already installed Linux SUSE 10, then complete that task now by
following the instructions below.
About this task
This task includes the steps to install the Telephony Application Server. Before
installing the Telephony Application Server, make sure that you have the following
items for installation:
v Minimum hardware requirements
v 4 CD's of SUSE Linux Enterprise Server 10 SP3 Installer DVDs of Telephony
Application Server
Procedure
1. Boot the machine from the CD1 SuSE Linux Enterprise Server 10 SP3. Select
Installation.
2. Select New Installation on the Installation Mode screen. Click Next.

3. At the Installation Settings screen, click Software.
4. At the Software Selections and Systems Task screen, disable Gnome, enable
KDE, then click Accept.
5. Disable the Change host name through DHCP option at the Host name and
Domain Name screen. Click Next.
6. Click the Firewall link at the Network Configuration screen.

7. Select Manually at the Firewall Configuration: Start-Up screen in the Service
Start Window. Click Accept.
8. Click the IPV6 link at the Network Configuration screen.
9. Select Disable IPv6 at the Network Setup Method screen. Click Next.
10. Click the Network Interface link at the Network Configuration screen.

11. Click Edit, at the Network Card Configuration Overview screen.
12. Select Static Address Setup, enter IP address and Subnet Mask, click host
name and name the server at the Network Address Setup screen.
13. Enter Host Name, Domain Name, Name Server 1 and click Ok at the Host
Name and Name Server Configuration screen.
14. Click Routing at the Network Address Setup screen.

15. Enter the Default Gateway and click Ok at the Routing Configuration screen.
16. Click Next at the Network Address Setup screen.
17. If there are more Network Interfaces, configure them and click Next at the
Network Card Configuration Overview screen.
18. Click the VNC Remote Administration link at the Network Configuration
screen.

19. Select Allow Remote Administration and click Finish at the Remote
Administration screen.
What to do next
After SUSE Linux has been installed, use YaST to manually deactivate the services
"novell-zmd" and "suseRegister".
Setting up failover services
Before you install any Telephony Application Servers in your IBM Lotus Sametime
Unified Telephony deployment, you need to set up failover services.
About this task
Lotus Sametime Unified Telephony uses IBM Tivoli System Automation for
Multiplatforms (SAMP) to provide failover services for Telephony Application
Servers. SAMP provides the following failover services:
v A high-availability environment, in which systems are continuously available
and whose self-healing infrastructure prevents downtime caused by system
problems.
v Automated control of system resources such as processes and file systems.
v Recovery and workflow processes that facilitate the automatic switching of
users, resources, and applications between clustered servers when a software or
hardware failure occurs.
This section explains the use of SAMP failover services in more detail, and then
provides instructions for installing the SAMP Base Component on a Telephony
Application Server.
Understanding failover services:
System Automation for Multiplatforms (SAMP) is an offering from Tivoli that is

used to provide failover services for Telephony Application Servers in an IBM
SAMP Features
v Provides high availability and automation. Reduces the frequency and duration
of incidents that impact IT availability.
v Automates the control of IT resources; for example, processes, file systems, and
so on.
v Automatic switching of users, resources, and applications from one system to
another in a cluster after a software or hardware failure.
v Addresses the three leading causes of unplanned outage:
– Hardware failure,
– Software failure
– Operator errors
SAMP provides a high-availability environment, in which systems are continuously

available and whose self-healing infrastructure prevents downtime caused by
system problems. The self-healing infrastructure detects improper operations of
systems, transactions, and processes, and initiates corrective actions without
disrupting users.
By providing high availability and automation services, SAMP reduces the

frequency and duration of incidents that impact IT availability. It is able to
guarantee this high availability by using fast outage detection and sophisticated
knowledge about application components and their relationships. It ensures quick
and consistent recovery of failed resources and complete business applications,
either on the same node or on a different standby system.

SAMP automates the control of IT resources; for example, processes, file systems,
and so on. It prevents failures by automating a recovery process or workflow. It
facilitates the automatic switching of users, resources, and applications from one
system to another in a cluster after a software or hardware failure.
SAMP provides this service by managing cluster-wide relationships among

resources for which it is responsible. If applications need to be moved among
nodes, the start and stop relationships, node requirements and any preliminary or
follow-up actions are automatically handled by SAMP. This relieves the operator
from manual command entry and reduces the risk of operator errors.
Finally, SAMP addresses the three leading causes of unplanned outage: hardware
failure, software failure, and operator errors.
SAMP Architecture
SAMP is composed of a base component which monitors resources through a

policy-based automation file. It also has an operations console which is a single
point of control for managing heterogeneous high availability solutions.
Base component
The SAMP base component resides on each node in a failover cluster, including the
standby node. Each base component includes an automation adapter. The
automation adapter of the base component of SAMP is required to establish and
manage the communication between the automation domains and the SA
operations console. On AIX and Linux systems, the adapter is installed
automatically with the base component.
Operations Console (optional)
The Operations Console provides a single point of control for managing

heterogeneous high availability solutions. The Tivoli System Automation for
Multiplatforms Operations Console is a web-based user interface that runs in the
IBM Integrated Solutions Console. The Integrated Solutions Console is a common
framework for administrative console functions which is built on WebSphere Portal
Server. To access the Operations Console, all that is required on the client is a web
browser. The SA Operations Console, is the main console for the System
Automation operator to perform daily operational tasks. For example, the
operations console can be used to start or stop applications without the need to
know their dependencies and without the need to have application-specific or
operating system-specific knowledge. Other typical operator tasks are: monitoring
the operational status of applications, diagnosing problems with automated
applications, switching between configuration choices for applications, excluding
nodes from automation for maintenance purposes, and more.
Note: There is no requirement to install the Operations Console, but instructions

are nonetheless provided on how to set up and configure the Operations Console.
However, all maintenance tasks can be performed using command-line invocations
on any system of the cluster such as any system installed with the base
component.
The Tivoli SAMP Web site is available for you to learn more about this product.
Failover and SAMP:
Failover for IBM Lotus Sametime Unified Telephony using IBM Tivoli System
Automation for Multiplatforms (SAMP).
The Telephony Application Server supports failover using a warm standby model.
Warm standby is a method of redundancy in which the standby system runs in the
background of the primary system.
In order to provide a highly available Sametime Unified Telephony cluster, one

standby node per cluster is the minimum supported deployment. There can be
more than one standby node if required. In an offboard deployment, a customer can
dedicate one standby server for all the Telephony Application Server, and a
separate standby server dedicated to the media servers.
By providing a failover model, if the Telephony Application Server fails, the

associated Telephony Control Server is able to route calls for the affected users
based on default settings. Furthermore, the warm standby node takes over for the
affected users that were provisioned to the failing Telephony Application Server.
Consequently, the loss of Sametime Unified Telephony services are measured in
minutes, not hours.
SAMP and Sametime Unified Telephony operation notes:
This section contains notes for operating System Automation for Multiplatforms
and IBM Lotus Sametime Unified Telephony.
System Automation for Multiplatforms (SAMP) watches and manages resources;

including Lotus Sametime Unified Telephony processes, the mounted Lotus

Sametime Unified Telephony directories, and the network interfaces – virtual IP
addresses. It uses technologies like HACMP, which is IBM's solution for
high-availability clusters.
The actions are implemented through xml policies, or more specifically, automation
policies. Therefore, SAMP enables you to configure high-availability systems
through the use of automation policies, in which the relationships among the
various components are defined. These policies can be applied to existing
applications with minor modifications. Once the relationships are established,
SAMP assumes responsibility for managing the applications on the specified nodes
as configured. This reduces implementation time and the need for complex coding
of applications.
The policies are based on polling, so every resource that you require to monitor
must be defined as a SAMP resource. As part of the definition of a SAMP resource,
commands to stop, start, and check that the status of the resource must be defined.
SAMP uses the monitor command to poll the resource at preset intervals. If the
resource is stopped it attempts to restart it. If that fails, the resources are switched
over to the standby node and started there.
These policies include rules whose parameters differentiate between "moving" and
"restarting" nodes. Move means "move" the virtual IP to an alternate system.
During the installation of a Telephony Application Server or Media Server in a
highly available cluster, the Telephony Application Server or media server are
installed with a virtual IP address. The Telephony Application Server/Media
Server is started with the virtual IP address. If the Telephony Application Server
fails, and SAMP is unable to restart on the same node, SAMP detaches the virtual
IP address from the existing node and switches it to the standby.
Once the move is accomplished, the policies specify data points to mount and the
actual mounting of those data points.
SAMP then uses the relationships and resources defined in the automation policy
to determine how to start each application, and the start sequence of those
applications.
The policies also contain the necessary information to stop applications.
Sametime Unified Telephony specific SAMP scripts:
These are your results when you set up a highly available IBM Lotus Sametime
Unified Telephony cluster.
v A script to generate the automation policy
v A response file that is used by the policy generation script
v A script to handle SAN mounts. This script is called sutctrl-data.sh
v A Script to monitor Lotus Sametime Telephony Software including start, stop
and monitor commands
v A script to allow SAMP to control WebSphere Application Server
You will receive files associated with the xml automation policy that defines your
SAMP domain. You will receive sample policies, but more importantly, you will
receive a script to generate an automation policy specific to your own
environment. This script is called generateAutomationPolicy.sh. In order to use
this script, you must first fill out a response file. The response file includes
information relative to each TAS, such as the TAS mount point ID, the WebSphere
Application Server mount point ID, the virtual IP addresses of the Telephony
Application Server and WebSphere Application Server, the SAMP domain name
and the automation policy name. This is covered in full in a later topic.
Once the policy has been generated, note that the policy file includes resources; for
example, VIPA and mount points; it also includes start sequence and relationships
as well as start, stop, and monitor script calls.
Once the failover cluster is in place and online, it can be monitored and controlled
through any node in the cluster, or through the Operations Console. You have
more control and autonomy through the command line. More detail can be found
in official SAMP documentation.
Note: All scripts are automatically installed during the installation of SAMP. The
scripts to control the mount points, TAS and WebSphere Application Server are
located in the following directory.
/usr/sbin/rsct/sapolicies/SUT
The script to generate the automation policy (and its associated response file) are
located under:
/software/IBM/Failover/tools
Deployment Overview:
There are two types of IBM Lotus Sametime Unified Telephony deployments
available: onboard and offboard.
Onboard Deployment
With an onboard deployment, all the functional elements exist on the same
machine, for example, Lotus Sametime Telephony Software, SIP Proxy, and
Registrar, Lotus Sametime Unified Telephony specific applications and the Media
Server all reside on the same machine. With this type of deployment, there are
scalability issues regarding conferencing services. Because the Media Server resides
on the same machine, there are not the same conferencing opportunities due to
hardware restraints. With an onboard installation, there is only one installation
response file.
Offboard Deployment
With an offboard deployment, Lotus Sametime Telephony Software, SIP Proxy and
Registrar, and Lotus Sametime Unified Telephony specific applications reside on
the one machine. The media server resides on a separate, dedicated machine. There
is the option of more than one media server per Telephony Application Server.
This is dependent upon the conferencing and announcement requirements of the
customer.
The following sections provide high-level descriptions of some of the possible

deployments.
Onboard deployment examples:
This topic contains a graphical representation of the smallest high availability

deployment available to you.

In this case we see an onboard deployment with a single Telephony Application
Server (TAS) box and the standard duplex Telephony Control Server (TCS). We can
also see a single standby server.
The cluster software (SAMP), the Telephony Application Server software, the
incorporated Media Server and SIP Proxy and Registrar are installed on the
primary node. The standby server is running, the operating system is up, and the
cluster software is actively monitoring the node. The database, as well as all
configuration data such as the WebSphere Application Server and Telephony
Application Server binaries are stored on a storage area network, or a SAN. The
hardware profile has to be identical for both servers. The software is fully installed
on the SAN Drive.
The SAMP operations console is not installed on any system in the cluster. It is
installed on a separate server. It is able to provide a web-based high-level view of
the cluster, once the base component automation adapter on the cluster nodes has
been configured.
If there is a failure, SAMP stops any remaining Telephony Application Server

components still running. Then the virtual IP address and mount points are
detached from the primary node and reactivated on the standby node. The
Telephony Application Server components are now restarted on the standby.
The next diagram illustrates e a more realistic real world failover cluster. In this
case, it shows a multiple Telephony Application Server (TAS) onboard deployment,
with a single standby server, to serve all Telephony Application Servers in the
event of a failure on any one of them.
Again, the cluster software is installed on each of the primary nodes. Standby
server is running, that is the operating system is up and the cluster software is up
and monitoring the node. Like the previous slide, the database as well as all
configuration data such as the WebSphere Application Server and Telephony
Application Server binaries are stored on the SAN.
The application data for each Telephony Application Server are stored on separate
SAN LUNs, or Logical Unit Numbers. A LUN is a reference to a specific disk area
in the SAN.
If there is a failure of one of the Telephony Application Server, SAMP releases the
specific mount points and reactivates them on the standby node using the relevant
SAN disk ID.
Offboard Deployment:
This section provides two offboard deployment diagrams.
This diagram shows a comprehensive failover-ready offboard environment. This

deployment uses multiple Telephony Application Servers (TAS) and multiple
Media Servers (MS), but just a single standby node. This standby node is
configured to be able to take over from any node in the cluster, be it a Telephony
Application Server or a Media Server.
The cluster software is installed on each of the primary nodes. The standby server
is running — the operating system is up — and the cluster software is up and
monitoring the node. In this case, all the application data is stored on the SAN,
including the media server application data.
If one of the Telephony Application Server or media servers fails, SAMP releases
the specific mount points and reactivates them on the standby node using the
relevant SAN disk ID. SAMP is then able to restart the application on the standby
node. Any maintenance can be carried out on the primary failed node at this time.

The next diagram describes the same scenario before, except multiple standby
nodes are included. In this scenario, any of the active Telephony Application
Servers (TAS) or Media Servers (MS) can be switched over to any of the standby
nodes in the event of a failure. It is a highly flexible failover model.
Failover use case description:
The following use cases have been considered in failover scenario.

v Failover to standby node
v Switch back to original system
v Update the software on a failover cluster
Each of these scenarios are described in full in their respective sections that follow.
Each section provides a high-level description of a particular failover scenario that
might be encountered in the day to day administration of a highly available SAMP
cluster.
Failover to standby node:
This section describes what causes a system to failover, and how the failover is
achieved.
Goal:
Detect a severe failure situation and initiate a failover to a standby node
Pre-Conditions:
v SAMP software is installed on all nodes (both active and standby nodes) and is
fully functional – it is monitoring the significant active software artifacts, for
example the Telephony Application Server and WebSphere Application Server
components.
v Standby node is running: Operation System up, Cluster SW up
v The database, as well as all configuration data is stored on a shared storage
system (SAN)
v The HW profile has to be identical for all nodes.
v The SW is fully installed on the SAN drive.
v For a Media Server installation, only a subset of the TAS components are
installed. For example, no database is used.
Description:
v SAMP detects a severe failure situation and decides to switch over to a stand-by
node.
v False failure situations such as a “planned shutdown” need to be excluded
v The system tries to shut down all running software artifacts, the database (if
used) and releases (un-mounts) the shared file system, and releases the virtual IP
address from the active/failing node
v The system attempts to gracefully shut down the failing node, but if that is not
possible, it forces a shutdown (OS level)
v Reconfigure or Activate the “external” IP address (for example Virtual IP
address) in order to make the standby node available for SUT clients
v The System becomes fully operational again, with the standby node replacing
the corrupted/failed node. From a client / service consumer perspective, the
system / cluster behaves like a single node that has been restarted.
v Client / Service consumers on other nodes reestablish connections to the new
server node
Post-Condition: .
v The System is fully operational again (now on the standby node)
v The System can be connected to by clients and other services using the same IP
address as before the switch over (such as through Virtual IP address).
v Failed node is out of operation, or running with only the OS active (for example
a SAMP resource is in FAILED OFFLINE state). It is possible to service the failed
node hardware and operating system (OS) such as apply the OS patches or even
reinstall the OS which is for example necessary after hard disc crash. It is not

possible however to update or patch the Telephony Application Server software
on the standby node, while it is active on another node. All Telephony
Application Server software updates must be performed on the physical system
where the initial installation took place
Note: The update on the standby node is not possible (RPM database inconsistent
between install and standby node). To update the system a switch back to the node
that was originally installed is necessary.
Failback to original node:
This section describes an administrator manual task, where a system that failed
over to standby due to some error condition can be returned to the original node.
Goal:
Original node is operating again.
Actor:
Administrator
Pre-Condition:
The previously failed system has been repaired and is able to operate again
Description:
The administrator triggers the Cluster Software manually, for example, using a
command-line interface, to switch over to the other node. More detail on how to
achieve this is covered in a later section: Failover Cluster Installation.
Post-Condition:
The other node is active and the previously active node is now, again, the standby
node. The system is fully operational again.
Software update on a failover cluster:
This is an administrator driven manual task.
Goal:
Assure a consistent installed SW version across the “cluster.”
Actor:
Administrator
Pre-Condition:
The previous failed system has been repaired and is able to operate again.
Description:
v The administrator sets the SAMP software to a “manual” mode to prevent
interactions during the update installation.
v The update must be performed on the system that the software was initially
installed, because the rpm database is only updated on that specific node.
v The Administrator stops the Telephony Application Server software and updates
the software as would normally be done on a single node system.
v During the update, the system is offline. The administrator activates the cluster
software again, by taking SAMP out of manual mode, and consequently SAMP
restarts the Telephony Application Server software.
Post-Condition:
v The System is fully operational again.
v The stand by node is running and prepared to take over in case of failure on
any active node.
Example Cluster:
This section provides a graphical representation of a typical failover installation.
Following picture describes the example scenario where three nodes are running
the different applications: TAS1 (Telephony Application Server), MediaServer1 and
MediaServer2. Both Media Servers are configured to provide conference and tone
channels. Each of the application could switch over to the standby node in case of
failure.
SAMP resource model:
All SAMP resources and dependencies are defined in a SAMP policy file based on
XML.
The SAMP policy describes the following:

v All resources that are monitored by the application and the dependencies
between the resources
v The network interfaces including the IP addresses
v The virtual IP addresses

v The tiebreaker - in our case the network tiebreaker is used with the IP address of
the default gateway
The following figure shows the resource modeling used for a Telephony
Application Server/Media Server installation on a resource group level.
Each BASE_TAS and BASE_MS resource group consists of a resource to mount the
file system on a SAN disk, /enterprise, and a resource to assign a virtual IP
address — VIPA or either a Telephony Application Server or Media Server.
The NODE_MGR_TAS consists of following resources:

v OSGi container (mandatory)
v Servlet Container / Tomcat (mandatory)
v ActiveMQ (mandatory)
v SNMP Receiver (optional)
v Notification Manager (optional)
The NODE_MGR_MS consists of following resources:

v OSGi container (mandatory)
v Notification Manager (optional)
The DB_MGR_TAS only contains a resource for the solid database.
To work properly, the NODE_MGR_TAS requires a running DB_MGR_TAS on the

same node (“StartsAfter” and “Collocated” relationship), as well as the assigned
virtual IP address and mounted file system provided by BASE_TAS (a
“DependsOn” relationship). The NODE_MGR_MS requires the assigned virtual IP
address and mounted file system provided by BASE_MS on same node
("DependsOn" relationship). Furthermore the Media Server must be started after
the Telephony Application Server, including the database (MS “StartsAfter” TAS).
To assure that an offboard Media Server and Telephony Application Server always
are running on different nodes the BASE_MS and BASE_TAS resource groups are
defined “AntiCollocated”).
SAMP Resource Model including WebSphere Application Server
To handle the WebSphere Application Server (WAS) the following resource model
has to be applied.
The NODE_MGR_WAS resource group consists of a single resource: WebSphere

Application Server
In this SAMP resource model there are only limited “DependsOn” relationships.
Since “DependsOn” also contains a “ForcedDownBy” relationship it will stop the
resource A if resource B goes down (for example NODE_MGR_TAS will be
stopped if BASE_TAS goes down). The WebSphere Application Server can be
stopped independent of Telephony Application Server, but has to be started before
Telephony Application Server (“StartAfter”). WebSphere Application Server has to
run on same node as TAS (“Collocated” (in both directions!)). The BASE_xxx
resources (mount points and virtual IP addresses) of WebSphere Application Server
and Telephony Application Server have to run on the same node (“Collocated”).
Note: For a more detailed description of these SAMP relationships, please refer to
the SAMP administrators guide, which can be found on the official SAMP site:
http://www-01.ibm.com/software/tivoli/products/sys-auto-multi/
Installing a failover cluster:

Use IBM Tivoli System Automation to set up a failover cluster in an IBM Lotus
Setting up prerequisites:
The following subsections describe in full the prerequisites that must be met before
installing a failover cluster in an IBM Lotus Sametime Unified Telephony
deployment.
SAN prerequisites:
This topic describes SAN-specific requirements that must be satisfied before

continuing with a failover cluster installation
About this task
A SAN is a Storage Area Network. A disk array that is accessed through FC

Installation instructions outside the scope of this topic.
Each active Telephony Application Server requires 2 LUNs (Logical Unit Number)
on the SAN, with a total of 20GB disk space:
v /enterprise - requires 10GB disk space
v /opt/IBM/WebSphere - requires 10 GB disk space
The standby Telephony Application Server does not count towards disk space
requirements. For example, if your deployment contains one active TAS and one
standby TAS, you will need a total of 20GB disk space for the SAN.
An offboard Media Server only requires 1 LUN on the SAN (/enterprise), with
10GB disk space
Procedure
1. Configuring SAN.
a. SAN installed and configured.
b. SAN LUNs configured
v LUN: Logical Unit Number.
c. The SAN is configured using a utility called Storage Manager.
v Use Storage Manager to create new logical drives and view logical drive
name to LUN mapping.
What follows is an example of a Telephony Application Server and separate
Media Server LUN Mapping table.
Note: 2 LUNs for a Telephony Application Serve, 1 LUN for a separate

Media Server.
d. Logical drives must be created on your SAN with 140 GB of size per
Telephony Application Server or Media Server node. Refer to the manual of
your SAN manufacturer on how to complete that task.
e. HBA cards installed on each host system, including standby nodes.
v HBA: Host Bus Adapter. The PCI card installed in the host to access the
SAN or SAN switch through Fibre Channel.
v Installation instructions outside the scope of this section, but further
information about how to configure HBA cards can be found under the
separate section “SAN Deployments.”
f. Connect the nodes to the SAN.
2. Ensure that the relevant directories exist on each node. Create the following
directories on every node in the cluster, including all standby nodes (directory
names are case sensitive):
/enterprise
/opt/IBM/WebSphere
3. Add mount points to /etc/fstab file.
Before you start with the further installation steps, you must prepare mount
points on all systems in such a way that the /enterprise partition for Telephony
Application Server or Media Server can be mounted on any node and similarly
the /opt/IBM/WebSphere can be mounted on any node for WebSphere
Application Server.
The device name must be adapted depending on partitioning of your SAN.
Since each TAS or Media Server installation uses an /enterprise mount point
there are several entries for the mount point /enterprise in the /etc/fstab file,
but all with different devices.
Note: The fstab file must contain entries for each ACTIVE node in the cluster.
The following example is a sample fstab file for a cluster of 2 TAS, 2 Media
Servers and 1+ stand-by nodes.
/dev/disk/by-id/scsi-3600a0b8000496cbe0000025348ce2b6c /enterprise
/dev/disk/by-id/scsi-3600a0b8000496cbe0000025448ce2b80
/opt/IBM/WebSphere ext3 noauto,acl,user_xattr 1 0
/dev/disk/by-id/scsi-3600a0b8000496cbe0000025548ce2b92
/enterprise ext3 noauto,acl,user_xattr 1 0
/dev/disk/by-id/scsi-3600a0b8000496cbe0000033a48f5f0e4
/enterprise ext3 noauto,acl,user_xattr 1 0
/dev/disk/by-id/scsi-3600a0b8000496cbe0000033b48f5f102
/opt/IBM/WebSphere ext3 noauto,acl,user_xattr 1 0
/dev/disk/by-id/scsi-3600a0b8000496cbe0000033c48f5f11c
/enterprise ext3 noauto,acl,user_xattr 1
It is important that the mounts are not auto-mounted which means that after a
reboot the system will not mount it (noauto option). Furthermore the value 0
must be set in last column, which means that the file system check will not run
automatically for this mount point. Otherwise, a file system check can be
started on the standby node after the reboot, although the file system is
mounted on another node and although it is not automatically mounted. If this
event happens, the fsck fails and the node will not install properly. Use an
editor to change /etc/fstab according to the example.
4. Check /etc/fstab settings.
Check if the mounts are working correctly on all nodes before continuing. Be
careful to never mount the same mount point on multiple nodes at the same
time. Log on to the first node, being aware to use the device name of your
installation, and call:

mount /dev/disk/by-id/scsi-3600a0b80003aafbc00003cf44897ad68-part1
If the system is correctly mounted you can check it by calling the mount
command without any options. It should print out the mounted devices.
Other prerequisites:
This section describes other non-SAN related requirements that must be satisfied
before continuing with a failover cluster installation.
Extra IP addresses
v 1 or 2 extra IP addresses per Telephony Application Server
– 1 extra if WebSphere Application Server and Telephony Application Server
reside on same IP address
– 2 extra if WebSphere Application Server and Telephony Application Server
have unique IP addresses
v 1 extra IP address per offboard Media Server
Host system configuration
Change /etc/hosts file to include the following line on each node:

127.0.0.2 localhost.localdomain localhost
Downloads
The download process is described in full in the section Downloading the

Telephony Application Server installation package. Follow these steps:
v Download the Telephony Application Server bundled software installer to the
software/IBM directory.
v Download all the Telephony Application Server or Media Server prerequisites
locally to the /software/IBM directory.
v Extract the tar file:
for example:
tar xvfz CZJJ1ML.tgz
v Verify that all media has been extracted to the following directory /software/IBM
v The extracted media includes all relevant software: cluster software SAMP,
Telephony Application Server software, IBM WebSphere Application Server,
scripts, and so on.
Installing SAMP:
Install the IBM Tivoli System Automation for Multiplatforms (SAMP) Base
Component before you begin installing the Telephony Application Server in your
IBM Lotus Sametime Unified Telephony deployment.
Before you begin
Ensure all the prerequisites have been satisfied and all media has been
downloaded to /software/IBM. The Tivoli SAMP V3.1 Base Component is included
in the Telephony Application Server installation package.
About this task
Additional information on installing the SAMP V3.1 Base Component is available

in the Installation and Configuration Guide.
Procedure
1. Log in to the server as root.
2. Navigate to the /software/IBM directory.
3. Run the following command to install SAMP:
./installSAMP.sh
The SAMP Base Component is installed.

4. After the SAMP Basic Component installation is finished, edit etc/profile and
add the following line (this can be placed at the end of the file):
export CT_MANAGEMENT_SCOPE=2
5. Explicitly set the CT_MANAGEMENT_SCOPE environment variable on each node –
from a terminal window invoke the following command:
export CT_MANAGEMENT_SCOPE=2
Creating a SAMP cluster:
This topic describes all the commands that must be invoked in order to create a
SAMP logical cluster.
Procedure
1. Issue the following command on every node in the cluster:
preprpnode node1 node2 nodeN
Include each node name in the command.

2. Create a domain to house the node by running the following command on one
node only:
mkrpdomain DOMAIN_NAME node1 node2 nodeN
Note: Any name can be selected for DOMAIN_NAME

3. From any node, start the domain:
startrpdomain DOMAIN_NAME
4. Verify that the domain is up and running (again, this command can be invoked
from any node).
lsrpdomain
An example output of “lsrpdomain” after the successful definition of a SAMP

cluster would be (in this example, Test1 was chosen as the domain name)
5. Verify that nodes are online.

lsrpnode

An example output of “lsrpnode” would be (where the nodes included in the
cluster were suttas1 and stx3455i)
6. Define a tie breaker on every node:

A tie breaker is required in a cluster with an even number of nodes. Without a
tie breaker, SAMP only automates resources when more than half the nodes in
a cluster are online. Therefore, in a two-node cluster, both nodes must be online
in order to automate resources. For our purposes, a tie breaker MUST be
created on every node.
a. Create the following directories under /var:
v /cf
v /cf/cfg
b. In /var/cf/cfg, create a file called netmon.cf (create this file on every
node).
See TSA documentation to learn more about Tie Breakers
c. The netmon.cf file contains the IP address of the host that should be used as
tie breaker.
It is recommended to use the default gateway for this purpose. But, any IP
address within the subnet that can be reached by all systems (at all times) is
sufficient.
The content of an example netmon.cf file, where the default gateway is
9.192.192.1 would be:
#This is default gateway for all interfaces in the subnet 9.192.192.0
9.192.192.1
d. Repeat this process to define a tie breaker on every node.
Editing the automation policy response file:
Modify the AutomationPolicyResponseFile_Onboard.txt or the

AutomationPolicyResponseFile_Offboard.txt file to provide values appropriate for
your IBM Lotus Sametime Unified Telephony deployment.
About this task
Use the automation policy response files to configure the Telephony Application
Servers and offboard Media Servers in the deployment. There are two automation
policy response files:
v AutomationPolicyResponseFile_Onboard.txt: Use this version of the file for an
onboard deployment, where each Media Server is installed directly onto a
v AutomationPolicyResponseFile_Offboard.txt: Use this version of the file for an
offboard deployment, where each Media Server is installed separately from any
Telephony Application Server. This version of the file contains additional settings
that are specifically used for the offboard Media Server.
Sample automation response files (located in /software/IBM/Failover/tools) have

been provided for two typical deployments:
v SampleResponsefile_1TAS_1Standby.txt: This sample represents the simplest
scenario, a deployment of a single active Telephony Application Server and a
single standby server. This sample is based on the
AutomationPolicyResponseFile_Onboard.txt file.
v SampleResponsefile_2TAS_2MS_2Standby.txt: This sample represents a more
complex secenario consisting of a cluster with two active Telephony Application
Servers, two standby servers, and two offboard Media Servers. This sample is
based on the AutomationPolicyResponseFile_Offboard.txt file.
Procedure
1. Navigate to the /software/IBM/Failover/tools directory and open either the
AutomationPolicyResponseFile_Onboard.txt or the
AutomationPolicyResponseFile_Offboard.txt file in a text editor.
You will only use one of the files, depending on whether you are using
onboard Media Servers or offboard Media Servers.
2. In the script, replace every occurrence of CRLF with LF to ensure the script
executes properly.
3. Fill in the following general fields; these fields are required:
Table 2. Required general fields
Field Description
Policy Name The name of the automation policy. This is the policy name that
you will use in the next step to activate the automation policy.
Domain Name The name defined in Step 2 above, when the SAMP cluster was
created using the ‘mkrpdomain' command.
Standby Node If there is a single standby node for all nodes in the cluster, enter
the host name in Standby_Node. If there are multiple standby
nodes for the cluster, enter the host names of all the standby
servers, comma-separated.
Note: Only use the short host names of the nodes; for example, if
the fully qualified domain name of your node is host123.zyx.com,
the short the host name is host123.
TAS_Network_ Network interfaces that will host the virtual ‘floating' IP addresses
Interface must be defined. If WebSphere Application Server and the
Telephony Application Server use the same IP address, only enter
a value for TAS_Network_Interface. A network interface typically
has a value of “eth0”, “eth1” and so on. Alternatively, if bonded
adapters are used, a value such as “bond0” would be used.
Note: Bonded adapters decrease the likelihood of a failover
condition due to a network switch. Information about how to set
up a bonded adapter is provided in the section that describes the
SAN deployments.
WAS_Network_ If WebSphere Application Server is going to have a separate IP
Interface address, then enter the WebSphere Application Server virtual IP
address value here.
Tie_Breaker A tie breaker is required in a cluster with an even number of
nodes. A network tie breaker should only be used for domains
where all nodes are in the same IP sub net. Although it is
recommended to use the default gateway IP address, this must
not be used if it is virtualized by the network infrastructure.
Provide an IP address that can only be reached through a single
path from each node in the domain.
Netmask The netmask of the IP address. The attribute must be given as a
character string, for example: 255.255.255.0.

4. Fill in the fields for the Telephony Application Server:
Table 3. Required Telephony Application Server fields
Field Description
App_Type Application type (accepted values are TAS, WAS, and MS). In this
section, the value should be TAS because you are supplying
information about an active Telephony Application Server.
TAS_Hostname: Host name of the machine on which the Telephony Application
Server is installed; for example: tas1. To determine the host name,
run the command "host name" on the node.
Node_ID: ID of install. Should correspond to ID file on the corresponding
mount point: TAS1, TAS2, and so on. This value does not have to
match the host name.
MOUNT_TAS: Mount point for Telephony Application Server software; for
example:
/dev/disk/by-id/scsi-3600a0b8000496cbe0000025378ht096
This is the value that the /enterprise folder is mapped to; you can
find it in the /etc/fstab file.
VIPA_TAS: Virtual IP address of the TAS. Ask your network administrator for
the address.
section, the value should be WAS, as the remaining values in this
section apply to the IBM WebSphere Application Server.
NODE_ID ID of install. Should correspond to ID file on the corresponding
mount point, for example. WAS1, WAS2, and so on.
VIPA_WAS Virtual IP address of WebSphere Application Server.
Note: This is left blank if Telephony Application Server and
WebSphere Application Server reside on the same IP.
MOUNT_WAS Mount point for Telephony Application Server software:
/dev/disk/by-id/scsi-3600a0b8000496cbe0098630jhf09823
This is the value that the /opt/IBM/Websphere folder is mapped to;

you can find it in the /etc/fstab file.
WAS_USERNAME Provide a user name for the WebSphere Application Server
administrator account on this node.
WAS_PASSWORD Provide a password for the same WebSphere Application Server
administrator account on this node.
5. For each active Telephony Application Server in the deployment, make a copy
of the Telephony Application Server section and edit it as appropriate.
Note: There is NO section in the response file for the standby server. Only the
active nodes are included.
6. (Offboard only) Fill in the values for an offboard Media Server:
This section appears only in the AutomationPolicyResponseFile_Offboard.txt
file because it is not needed for an onboard deployment.
Table 4. Required offboard Media Server fields
Field Description
section, the value should be MS because you are providing details
about the offboard Media Server.
Table 4. Required offboard Media Server fields (continued)
Field Description
MS_Hostname Host name of the machine on which the Media Server is installed;
for example: ms1
Node_ID ID of install. Should correspond to ID file on the corresponding
mount point for example MS1, MS2, and so on.
VIPA_MS Virtual IP address of Media Server.
MOUNT_MS Mount point for Media Server software: /dev/disk/by-id/scsi-
3600a0b8000496cbe0098098432h
7. For each offboard Media Server in the deployment, make a copy of the
offboard Media Server section and edit it as appropriate.
Example
Provided below is a sample automation policy for a cluster consisting of one

Telephony Application Server, one standby server, and one offboard Media Server
(using the AutomationPolicyResponseFile_Offboard.txt file).
#######################################################################
#Generic Domain details. Required here are the name of the automation domain,
and all
#the nodes that will make up the domain (including standby nodes). Also
included are
#network equivalencies and the network tie-breaker
#######################################################################
#Provide a name for the automation policy file
Policy_Name: SUT_Test_Policy
#Name of the failover cluster

Domain_Name: SUT_Test
#If there is a single standby node for all nodes in the cluster, enter the
#hostname in #Standby_Node. If there #are multiple standby nodes for the
#cluster, enter the hostnames #of all the standby servers, comma-#separated
# - enter the node name of the standby TAS in Standby_Node
Standby_Node: host123
#Network interface names for example eth0, eth1

#N.B. - If WAS and the Framework use the same IP address, only enter a
#value for TAS_Network_Interface.
# - If WAS is going to have a separate IP address, then enter a value
#for WAS_Network_Interface.
TAS_Network_Interface: eth0
WAS_Network_Interface:
#Enter the default network gateway for example 192.192.192.1

Tie_Breaker: 10.10.120.1
#The cluster Netmask

Netmask: 255.255.252.0
########################################################################
# Each section represents the details of an ACTIVE TAS or an ACTIVE

# Media Server - A TAS server contains both the TAS software (the
#framework) and the WAS
# software. Therefore a TAS node contains details of TAS and WAS mount
#points and virtual
# IP addresses (VIPA only required for WAS # if TAS and WAS reside on
#different IP addresses)
# - A media server only contains details of a media server application

#such as mount point,
# virtual IP address, ID and so on
#
#N.B. - Do not include a section for the standby server
########################################################################
########################################################################
# TAS Details
########################################################################
#Type of installation such as TAS, WAS or MS. In this case, TAS
App_Type: TAS
#Hostname of the machine. invoke the command "hostname" on the node to

#determine for example host123
TAS_Hostname: tas1
#ID of install. Should correspond to ID file on the corresponding mount

#point for example TAS1, TAS2 and so on
Node_ID: TAS1
# Virtual IP Address (VIPA) of TAS.

VIPA_TAS: 10.10.122.74
#Mount points for TAS software

MOUNT_TAS: /dev/disk/by-id/scsi-3600a0b8000496cbe0000025348ce2b6c
#Type of installation such as TAS, WAS or MS. In this case, WAS

App_Type: WAS
#ID of install. Should correspond to ID file on the corresponding mount

#point for example WAS1, WAS2 and so on
Node_ID: WAS1
# Virtual IP Address (VIPA) of WAS.

VIPA_WAS:
#Mount points for WAS

MOUNT_WAS: /dev/disk/by-id/scsi-3600a0b8000496cbe0000025448ce2b80
#Username for WAS on this node

WAS_USERNAME: was_admin_name
#Password for WAS on this node

WAS_PASSWORD: was_admin_passw0rd
# End of TAS Details

########################################################################
########################################################################
# Offboard Media Server Details
########################################################################
#Type of installation such as TAS or MS
App_Type: MS
#Hostname of the machine. invoke the command "hostname" on the node to

#Sdetermine MS_Hostname: ms1
#ID of install. Should correspond to ID file on the corresponding mount point

Node_ID: MediaServer1
# Virtual IP Address (VIPA) of TAS

VIPA_MS: 10.10.122.75
#Mount points for Media Server files

MOUNT_MS: /dev/disk/by-id/scsi-3600a0b8000496cbe0000025548ce2b92
#End of Media Server details
########################################################################
Generating and activating policy:
Generate the automation policy for an IBM Lotus Sametime Unified Telephony
deployment using the response file that you created previously.
Procedure
1. Ensure that the generation script is executable by running the following
command:
- chmod 777 generateAutomationPolicy.pl
2. Generate the policy using the generateAutomationPolicy.pl script.
./generateAutomationPolicy.pl -i automation_policy_response_file.txt
where automation_policy_response_file.txt is the response file that you
edited in the previous task. If you modified one of the provided templates for
your response file, it uses one of the following names:
v AutomationPolicyResponseFile_Onboard.txt
v AutomationPolicyResponseFile_Offboard.txt
The output from this command should look like this example:
Generating SAMP policy using response file: AutomationPolicyResponsefile.txt...
...
Generated SAMP policy: SUT_Policy2.xml
3. Verify that the policy is valid with the following command:
sampolicy -c policy_name.xml
4. If the policy is valid, activate the policy the following command
sampolicy -a policy_name.xml
5. If the policy is activated without problem, the system responds with a message.
Automation policy notes:
Note the following points about the generated automation policy:

v The automation policy consists of high-level resource groups. In order to control
the domain, it is necessary to understand the naming conventions that are used
v To start up the Telephony Application Server and WebSphere Application Server
mount points and virtual IP addresses, invoke
chrg –o online SUT_BASE_TASx
chrg –o online SUT_BASE_WASx

Where x is the node ID, for example. 1, 2, 3, and so on.
v Starting up a Telephony Application Server involves starting the Solid DB, the
Telephony Application Server framework and WebSphere Application Server.
v To start up a Telephony Application Server, it is only required to invoke one
command such as
chrg –o online CLUSTER_TASx
Where x is the node ID

v To start up the mount point and VIPA of an offboard Media Server, invoke
chrg –o online SUT_BASE_MediaServerX
Where X is the node ID

v To start up an offboard media server, invoke
chrg –o online NODE_MGR_MediaServerX
Where X is the node ID
Installing the TAS application

After setting up failover services, prepare the response file and install the IBM
Lotus Sametime Unified Telephony application.
Preparing the response file:
Prepare the response file for use when installing a Telephony Application Server
into an IBM Lotus Sametime Unified Telephony deployment.
Before you begin
Before installing the Telephony Application Server software, do the following:

v SUSE Linux Enterprise Server 10 SP3 must be installed.
v You have configured the network cards.
v Ensure that you have the installer DVDs of the Telephony Application Server
software.
About this task
You must prepare the response file manually. This file contains the IBM WebSphere
Application Server parameters, Lotus Sametime Unified Telephony parameters,
Telephony Application Server parameters, and SolidDB parameters.
There are different forms of response files available depending on whether you are
using an onboard or offboard installation, or whether you are installing Telephony
Application Server or the Media Server. Use the Telephony Application Server's
own IP address wherever the Telephony Application Server IP is requested. Use
the Media Server's virtual IP address (VIPA) wherever the Media Server IP is
requested. Use the Telephony Application Server's virtual IP address (VIPA) for the
SIP proxy server's IP address.
Procedure
1. Prepare the Lotus Sametime Unified Telephony response file.
v For an onboard installation use the
responsefile.txt.TEMPLATE.TAS_Node_Small_Deployment file.

v For an offboard Telephony Application Server installation, use the
responsefile.txt.TEMPLATE.TAS_Node_Medium_Deployment file.
v For an offboard Media Server installation, use the
responsefile.txt.TEMPLATE.Media_Server_Node_Medium_Deployment file.
2. Using PuTTy, open the responsefile.txt using the following command:
/software/IBM # vi responsefile.txt.
3. Specify all properties in the responsefile.txt:
•WAS_USERNAME
It is used by the installer to create a WebSphere administrator username
when installing WebSphere Application Server and to log into WebSphere
when deploying and undeploying applications(EAR, WAR, and so on).
Example: WAS_USERNAME=wasadmin
•WAS_PASSWORD
It is used by the installer to create a password for the username specified
in WAS_USERNAME property.
Example: WAS_PASSWORD=pasbw2dfg7
•WAS_IP
It is one of the IP addresses or virtual IP address in fail-over
configuration of the machine where WebSphere Application Server is installed.
Enter one of the two IPs that are configured for this server.
The other IP should be entered into the TAS_IP section.
Example: WAS_IP=192.168.232.128
•SUT_USERNAME
It is used by the installer to create a user in WebSphere, when installing
WebSphere, for Sametime Unified Telephony administration purposes. When
this user logs into WebSphere he can only see Sametime Unifief Telephony
applications.
Example: SUT_USERNAME=sutadmin
•SUT_PASSWORD
It is used by the installer to create a password for the username specified
in SUT_USERNAME property.
Example: SUT_PASSWORD=ituy7ngsd9o
•TAS_USERNAME
It is the TAS (CMP) administrator username and is used by installer when
installing sutadmin applicationsin WebSphere.
Example: TAS_USERNAME=administrator
•TAS_PASSWORD
It is the password for the TAS (CMP) administrator specified in TAS_USERNAME.
Example: TAS_PASSWORD=abc1def?GH
•TAS_IP
It is the IP address (or virtual IP address in fail-over configuration)
of the machine on which TAS is installed and is used by installer when
installing sutadmin applicationsin WebSphere and is used for a deployment
type of TAS_NODE_SMALL or TAS_NODE_MEDIUM.
Enter one of the two IPs that are configured for this server.
The other IP should be entered into the TAS_IP section
Example: TAS_IP=192.168.232.128
•MEDIA_SERVER_IP

It is the IP address (or virtual IP address in fail-over configuration) of
the machine on which the Media Server is installed. This value is used for
a deployment type of MEDIA_SERVER_NODE_MEDIUM.
Example: MEDIA_SERVER_IP=9.123.53.90
•MEDIA_SERVER_NAME
It is the name of the Media Server. This value is used for a deployment
type of MEDIA_SERVER_NODE_MEDIUM.
Example: MEDIA_SERVER_NAME=Media Server 1
•NODE_MEDIA_SERVER_1_IP
of the machine on which the Media Server is installed. This value is used
for a deployment type of TAS_NODE_MEDIUM.
Example: NODE_MEDIA_SERVER_1_IP=9.123.53.90
•NODE_MEDIA_SERVER_1_NAME
type of TAS_NODE_MEDIUM.
Example: NODE_MEDIA_SERVER_1_NAME=Media Server 1
•NODE_MEDIA_SERVER_2_IP
of the machine on which the Media Server is installed. This value is used
for a deployment type of TAS_NODE_MEDIUM.
Example: NODE_MEDIA_SERVER_2_IP=9.123.53.91
•NODE_MEDIA_SERVER_2_NAME
type of TAS_NODE_MEDIUM.
Example: NODE_MEDIA_SERVER_2_NAME=Media Server 2
•SI_COMMUNITY_NAME
It is the unique ID for each TAS and/or Media server and for a TAS Medium
installation the SI_COMMUNITY_NAME must be the same for both TAS and Media
server
Example: SI_COMMUNITY_NAME=Some_Unique_ID
•FORCE_ROUTING_URL
The IP address used here is the one you assigned to the sipsm1_vip parameter
in the node.cfg file during the Telephony Control Server configuration.
It is the IP address and port number of the B2BUA (Back-to-Back User Agent)
that a proxy request needs to be routed to if the enforcement mechanism is
provided, and its format must be a valid sip URL such as sip:<IP address>:<port>.
This value is used by the installer when installing the SIP application in WebSphere.
# e.g. FORCE_ROUTING_URL=sip:9.123.53.33:5060;transport=tcp
# e.g. FORCE_ROUTING_URL=sips:9.123.53.33:5061;transport=tls
Example: FORCE_ROUTING_URL=sip:9.123.105.72:5060;transport=tcp
•COMMUNITY_HOST It is the IP address or hostname of a Sametime server and is

used by installer when installing OSGi bundles in Symphonia.
Example: COMMUNITY_HOST=192.168.232.128
•SOFTPHONE_PREFIX They are digits required by the TCS (Telephony Control

Server) to route a call to the SIP proxy/registrar in WebSphere and they
are used by installer when installing OSGi bundles in Symphonia.
Example: SOFTPHONE_PREFIX=7111

•SIP_PROXY_IP It is the IP address (or virtual IP address in fail-over
configuration) of the SIP proxy/registrar in WebSphere and they are used
by installer when installing OSGi bundles in Symphonia.
Example: SIP_PROXY_IP=192.168.232.128
•STI_QUEUE_NUMBER It is the number used to reach the queue device and is

Example: STI_QUEUE_NUMBER=+15555741100
•STIGNF_PREFIX_REPLACEMENT It is the sequence of digits used to replace

the plus sign "+" when dealing with the TCS (Telephony Control Server)
numbering plans and is used by installer when installing OSGi bundles in
Symphonia.
Example: STIGNF_PREFIX_REPLACEMENT=00
•CONNECTING_SERVER_DNS It is the qualified DNS name of the Sametime server

and is used by installer when installing OSGi bundles in Symphonia.
Example: CONNECTING_SERVER_DNS=web.company.com
•TELEPHONY_USERID_DOMAIN_SUFFIX It is the domain suffix for the supported

user ID and is used by installer when installing OSGi bundles in Symphonia.
Example: TELEPHONY_USERID_DOMAIN_SUFFIX=system
•STI_QUEUE_TIMEOUT_DEFAULT It is the default number of seconds that the

queue will ring before deflecting to the next device in the list and is
Example: STI_QUEUE_TIMEOUT_DEFAULT=10
•STI_DEFAULT_RNA_TIMEOUT It is the default number of seconds that a device

will ring before deflecting to the next device in the list and is used by
installer when installing OSGi bundles in Symphonia.
Example: STI_DEFAULT_RNA_TIMEOUT=10
•STI_CONFERENCE_DEVICES It is a list of conference devices associated with a

Example: STI_CONFERENCE_DEVICES=+15819991000,+15819991001
•TAS_DEPLOYMENT_TYPE It is the TAS deployment type. This property can only

have three values: TAS_NODE_SMALL, TAS_NODE_MEDIUM and
MEDIA_SERVER_NODE_MEDIUM.
TAS_NODE_SMALL means all TAS applicationswill be installed on the same

machine.
TAS_NODE_MEDIUM is used to install all applicationson the same machine

but the Media Server.
MEDIA_SERVER_NODE_MEDIUM is used to install only the Media Server on its

own dedicated machine.
Example: TAS_DEPLOYMENT_TYPE=TAS_NODE_SMALL
Installing the Telephony Application Server:
To install the Telephony Application Server, choose the primary node of the cluster
where the installation is to be performed.

Before you begin
You must have edited and saved the appropriate response.txt file in the previous
topic.
About this task
After the installation, you will need to create an ID file on each mount point. The
cluster will not run as expected without the ID files.
Procedure
1. Use SAMP to start the Telephony Application Server and IBM WebSphere
Application Server mount points and virtual IP addresses by running the
following command:
chrg –o online SUT_BASE_TASx SUT_BASE_WASx
2. Set the cluster on manual mode with the following command:
samctrl -M T
If this command is not issued, the installation in a SAN deployment fails
because SAMP will switch to another drive and the WebSphere Application
Server will not be available under the /opt/IBM/Websphere/ path as expected.
3. Install Sametime Unified Telephony. Log on to the primary node on which the
TAS installation is to be performed. For a fresh installation:
a. Log in as root.
b. Issue the following command to install the TAS software: ./install.sh all
c. Type yes when prompted to agree to the licenses.
The installation takes approximately 45 minutes.
4. After a successful installation, create ID files on each mount point. The ID files
are created in order to identify the installed system. The name of the file must
correlate with the NODE_ID definitions in the automation policy responsefile
file. For example, a TAS installation can be identified by a file called TAS1; a
WebSphere Application Server installation can be identified by a file called
WAS1; a Media Server installation can be identified by a file called MediaServer1.
Log in as root and execute the following commands:
v touch /enterprise/TAS1 for a TAS.
v touch /opt/IBMWebSphere/AppServer/WAS1 for a WebSphere Application
Server. This command creates empty files to identify the servers.
v touch /enterprise/MediaServer1 for a Media Server on a separate Media
Server node.
Configuring the failover services

This section describes the tasks involved in configuring failover on the TAS.
Bringing the Telephony Application Server nodes online:
After the Telephony Application Server software has been installed on the primary
node in the IBM Lotus Sametime Unified Telephony cluster and you have created
ID files for each mount point, you can bring the primary TAS node online.
Before you begin
You must have created the ID files on each mount point in the cluster. These are
only created on the mounted directories, not on any particular system.

About this task
To bring the node online, SAMP must be taken out of manual mode. You can then
start and verify that the Telephony Application Server is up and running. SAMP
must have total control over all cluster components, including processes that run
on startup.
Procedure
1. Take SAMP out of manual mode with the following command:
samctrl -M F
2. Start the Telephony Application Server with the following command:
chrg -o online CLUSTER_TASx
Where x is 1, 2, 3... or
chrg NODE_MGR_MediaServerX
If the node is a Media Server and x is 1, 2, 3...

3. Verify that the Telephony Application Server has started using the command:
lssam
Here is an example output from 'lssam'
4. To prevent automatic startup of system components (Telephony Application

Server, WebSphere Application Server, and Solid database), issue the following
commands:
chkconfig symphoniad off
chkconfig solidSYM off
chkconfig websphere off
Note the “Failed Offline” status of the standby node:
Standby node requires specific scripts from the primary node. Without these
scripts, the standby is unable to take over from the primary node in the event
of an unrecoverable software or hardware failure. Preparation of the standby
node is covered in detail in an upcoming topic.
Performing remaining Telephony Application Server installations:

Telephony Application Server software must be installed on every remaining
Telephony Application Server/Media Server node in the cluster, except the standby
nodes.
About this task
Now, you can perform all the remaining Telephony Application Server
installations. Remember to perform these tasks for each node in the cluster.
Procedure
1. Bring the mount points and virtual IP address online first: For TAS1:
chrg -o online SUT_BASE_TAS1 SUT_BASE_WAS1
For TAS2:
chrg -o online SUT_BASE_TAS2 SUT_BASE_WAS2, and so on
2. Put SAMP into manual mode.
samctrl -M T
3. Prepare the Sametime Unified Telephony response file.
4. Install the Telephony Application Server software.
./install.sh all
5. Create ID files on the mount points if you have not already done so, for
example: On TAS2:
touch /enterprise/TAS2 and
touch /opt/IBM/WebSphere/Appserver/WAS2
6. Take SAMP out of manual mode
samctrl -M F
7. Start the Telephony Application Server, for example: For TAS 3:
chrg -o online CLUSTER_TAS3
8. Invoke the commands that prevent automatic startup of the Telephony
Application Server components:
Installing offboard Media Servers (optional):
You can optionally install an off board Media Server after the Telephony
Application Server software installation, depending on customer requirements.
Before you begin
If you are going to install an off board Media Server, ensure that the corresponding
Telephony Application Server is running.
Procedure
1. To ensure that the corresponding Telephony Application Serve is running, use
the following command:
lssam
Or invoke the following on the actual Telephony Application Server node:

/etc/init.d/symphoniad status

2. Bring the mount point and VIPA online, for example, for MediaServer1, use
the command:
chrg -o online SUT_BASE_MediaServer1
3. Verify the mount point and VIPA are online. Use the following command
(example output below):
lssam
4. Log in to the node where you will perform the Media Server installation.
5. Prepare the Media Server responsefile.txt using the following template (can
be found under /software/IBM/:
responsefile.txt.TEMPLATE.Media_Server_Node_Medium_Deployment
6. Put SAMP in manual mode using the command:
samctrl -M T
7. Using the Sametime Unified Telephony installer, install the Media Server only.
Use the following command:
./install.sh ms
8. Create the ID file on the Media Server mount point using the command:
touch /enterprise/MediaServer1
9. Take SAMP out of manual mode:
samctrl -M -F
10. Start the Media Server, for example, for Media Server 2
chrg -o online NODE_MGR_MediaServer2
11. Verify that the Media Server is running with the command (example output
below):
lssam
12. Invoke the commands to prevent automatic startup of the Telephony

Application Server components:
Preparing standby nodes:
After successful installation of the Telephony Application Server and the Media
Server in your IBM Lotus Sametime Unified Telephony deployment, you must
copy some additional files, such as the start scripts in /etc/init.d/, to the standby
nodes. A specialized script, coldStandby.sh, is provided for this purpose.

Procedure
1. Prepare the standby node.
a. Save TAS rs-scripts and configuration files using the command:
/enterprise/servicetools/install/bin/coldStandby.sh -s
b. Stop the Telephony Application Server using the command:
chrg -o offline CLUSTER_TAS1
c. Switch the cluster to the standby node using the following command:
rgreq -o move -n node1 SUT_BASE_TAS1
Where node1 is the node on which Telephony Application Server is

running.
d. Check if the switchover was successful:
lssam
e. Log on to the standby node and verify the switchover. Check /enterprise
to verify the presence of the ID file – ensure the TAS1 is present.
2. Restore TAS rc-scripts and configuration files.
/enterprise/servicetools/install/bin/coldStandby.sh –r
/enterprise/var/coldStandby
3. If not already present, create a log directory on the second node as follows:
mkdir /log
chmod 777 /log
4. Reset the resources that are in the FAILED offline state:
resetrsrc -s ’Name like "%"’ IBM.Application
Note: Once SAMP resources reach a FAILED offline state, you must reset
them manually.
5. Prevent the automatics startup of system components.
6. Check for the presence of the symbolic link:
ls -al /usr/lib/liblog4cxx.so
If the symbolic link exists, the reply will indicate where the link points. If the
link does not exist, create one as follows:
ln -s -T /enterprise/mediaserver/application_host/bin/liblog4cxx.so
/usr/lib/liblog4cxx.so
7. Bring the node online on the standby node.
chrg -o online CLUSTER_TAS1
8. Verify that all components are running as expected:
lssam
9. Reset resources that are in the FAILED offline state:
10. Fail back to the primary node.
rgreq -o move -n <standby_node> SUT_BASE_TAS1
where standby_node is the host name of the standby node.
Updating the Telephony Control Server configuration:

You must add the virtual IP address of the Telephony Application Server to the
packet filter rules of the Telephony Control Server.
Procedure
1. Start the Telephony Control Server command-line interface in standard (not
expert) mode:
startCli
2. Select 6, 8, 4, create.
3. Add the following 11 rules for Telephony Application Server IP. This has to be
made for all Telephony Application Servers which uses the CMP to access the
---------------------------------------------------------------
Packet Filter Rule Name: TAS1_PHY
Description: SNMP Packets from TAS1 to Node IP
Remote FQDN:
Remote IP Address: <Virtual IP Address of TAS1>
Remote NetMask: 255.255.255.255
Remote Port Begin: 0
Remote Port End: 0
Direction: InComing
Local Host : bond_node_alias
Local Port Begin: 161
Local Port End: 0
Transport Protocol: UDP
Action : Allow
---------------------------------------------------------------
Packet Filter Rule Name: TAS1_PHY_FTPC
Description: FTP Control from Trusted TAS1 to Node IP
Remote FQDN:
Remote Port End: 0
Direction: InComing
Local Port End: 0
Transport Protocol: TCP
Action : Allow
---------------------------------------------------------------
Packet Filter Rule Name: TAS1_PHY_FTPD
Description: FTP Data from TAS1 to Node IP
Remote FQDN:
Remote Port End: 0
Direction: InComing
Local Port End: 0
Action : Allow
---------------------------------------------------------------
Packet Filter Rule Name: TAS1_SOAP_Node
Description: SOAP from TAS1 to Node IP
Remote FQDN:
Remote Port End: 0
Direction: InComing

Local Port End: 0
Action : Allow
---------------------------------------------------------------
Packet Filter Rule Name: TAS1_VIP
Description: SNMP Packets from TAS1 to OAM Virtual IP
Remote FQDN:
Remote Port End: 0
Direction: InComing
Local Host : oam_ip_alias
Local Port End: 0
Action : Allow
---------------------------------------------------------------
Total Number of Packet Filter Rules Retrieved : 10
Packet Filter Rule Name: TAS1_FTPC
Description: FTP Control from Trusted TAS1 to OAM Virtual IP
Remote FQDN:
Remote Port End: 0
Direction: InComing
Local Port End: 0
Action : Allow
---------------------------------------------------------------
Packet Filter Rule Name: TAS1_FTPD
Description: FTP Data from TAS1 to OAM Virtual IP
Remote FQDN:
Remote Port End: 0
Direction: InComing
Local Port End: 0
Action : Allow
---------------------------------------------------------------
Packet Filter Rule Name: TAS1_DB
Description: Solid DB Access from TAS1 to OAM Virtual IP
Remote FQDN:
Remote Port End: 0
Direction: InComing
Local Port End: 0
Action : Allow
---------------------------------------------------------------
Packet Filter Rule Name: TAS1_SFTP
Description: SFTP from TAS1 to OAM Virtual IP
Remote FQDN:

Remote Port End: 0
Direction: InComing
Local Port End: 0
Action : Allow
---------------------------------------------------------------
Packet Filter Rule Name: TAS1_SOAP
Description: SOAP from TAS1 to OAM Virtual IP
Remote FQDN:
Remote Port End: 0
Direction: InComing
Local Port End: 0
Action : Allow
---------------------------------------------------------------
Total Number of Packet Filter Rules Retrieved : 1
Packet Filter Rule Name: SnmpOffBoardAssistant2_<Virtual IP Address of TAS1>
Description: SNMP Packets from Assistant Server to bond partner IP
Remote FQDN:
Remote Port End: 0
Direction: InComing
Local Host : bond_partner_alias
Local Port End: 0
Action : Allow
---------------------------------------------------------------
Testing the failover installation:
This topic describes some of the failover tests you can perform on the primary and
standby Telephony Application Server nodes.
About this task
There are several tests that you can execute to verify that the failover installation is
working. The following tests are general guidelines for these components.
Procedure
1. Reboot the active node. It is expected that the switchover is successful, and that
the times are comparable with a manual switchover.
2. Power off the active node. Check to see if the switchover is successful.
3. Disconnect the network cable to the outside network. Check to see if the
switchover is successful.
4. Switchover to the standby node while the mount is busy, for example, by an
opened shell that changes to the mounted directory. The expected result is the
switchover is successful and that the shell has been closed.
5. Manually stop the processes, using this command:
symphoniad stop

The expected result is a quick restart of the processes on the same node – no
switch over.
6. Manually test a switch over. To switch over call the following command:
rgreq -o move -n <node> BASE_TAS1
Where node is the currently active node. Use the lssam command to see which
node is currently active.
Updating or uninstalling components:
You can update or uninstall any of the components, for example Telephony
Application Server, WebSphere Application Server, or the Media Server.
About this task
You can manage the components by uninstalling or updating the Telephony

Application Server, WebSphere Application Server, or Media Server. The following
steps are general guidelines for these components.
Procedure
1. Switch the resources to be updated to the node where the original installation
was performed. The rpm database is consistent on the primary node. Use the
rgreq commands.
2. Set the cluster on manual mode:
samctrl -M T
3. Perform the update or uninstall according to the installation instructions, for
example, to uninstall and reinstall the OSGI container:
./uninstall.sh osgi
./install.sh osgi
4. To update, set the cluster back to automatic mode:
samctrl -M F
Failover monitoring and maintenance

This section describes the tasks involved in monitoring and maintaining the
failover cluster on the TAS.
Starting and stopping services in a failover environment:
Starting and stopping IBM Lotus Sametime Unified Telephony services in a

failover environment require different commands from servers that are not running
in a failover environment.
Starting SUT services
Use the following command to start Lotus Sametime Unified Telephony services in
a failover environment:
chrg -o online SUT_BASE_TASx SUT_BASE_WASx CLUSTER_TASx
where x is the node ID.
Attention: It is important that the nominal state of the Telephony Application

Server and the IBM WebSphere Application Server base group is online at all times
when a Telephony Application Server is running.

Stopping SUT services
Use the following command to stop Lotus Sametime Unified Telephony services in
a failover environment:
chrg -o offline CLUSTER_TASx
Issuing the above command stops services running on the Telephony Application
Server. However, the Telephony Application Server and WebSphere Application
Server mount points will still be online and under the control of SAMP. To stop
everything and unmount the disks, use the following command:
chrg -o offline SUT_BASE_TASx SUT_BASE_WASx CLUSTER_TASx
Guidelines for administering a failover cluster - Important notes:
When administering a failover cluster in an IBM Lotus Sametime Unified

Telephony deployment, it is important to use SAMP control commands and to
avoid dual-mounting SAN disks.
Administration guidelines
When administering a failover cluster, it is important to follow these basic

guidelines:
Use SAMP commands to control the Telephony Application Servers
In a failover cluster, always use IBM Tivoli System Automation for Multiplatforms
(SAMP) commands to control the Telephony Application Servers.
Examples:
v To stop Lotus Sametime Unified Telephony services, use the SAMP command:
- chrg -o offline CLUSTER_TASx
rather than the native command:

- /etc/init.d/symphoniad stop
v To unmount the SAN disk (/enterprise), use the SAMP command:
- chrg -o offline SUT_BASE_TASx
instead of the native command:

- unmount /enterprise
All commands for controlling the cluster are described in Using the command line
for SAMP monitoring and maintenance.
Avoid dual mounting the SAN disks
It is very important to avoid dual mounting the SAN disks on both the primary
and standby nodes. If you use only SAMP commands to control the Telephony
Application Servers, this will never occur. Be aware that while SAMP controls the
cluster services, it also controls the mount points.
Put SAMP into manual mode before using native commands

If, for any reason, it is necessary to control a Telephony Application Server with
the native commands, ensure that SAMP is first put in manual mode by running
the following SAMP command:
- samctrl -M T
Lotus Sametime Unified Telephony services for that Telephony Application Server
can then be stopped and started using the native commands.
Using the command line for SAMP monitoring and maintenance:
This topic describes some SAMP monitoring and maintenance tasks that can be
performed using the command-line interface (CLI).
The SAMP has the following useful commands from the CLI:
v For all SAMP commands, UNIX man-pages are available.
man command_name
v Monitor the cluster state:
lssam
v Monitor the system permanently:
lssam -top
v Set Automation to manual mode, that is, for installation, update, and so on:
samctrl -M T
v Set Automation to automatic mode:
samctrl -M F
v Reset the state of a resource (recover from Failed offline):
– Reset the resource DB_MGR when it is in Failed offline state:
resetrsrc -s ’Name="DB_MGR"’ IBM.Application
– Reset all resources:
v Start / Stop resource group SUT_BASE_TASx:
(SUT_BASE_TASx controls the /enterprise mount point and the TAS virtual IP
address)
chrg -o online SUT_BASE_TASx
chrg -o offline SUT_BASE_TASx
v Bring down the active TAS node:
chrg -o offline CLUSTER_TASx
where x can be 1, 2, 3, and so on.

v To bring up a TAS node that is currently offline:
chrg -o online CLUSTER_TASx
where x can be 1, 2, 3, and so on.

v Policy operations:
– Check policy:
- sampolicy -c policy.xml
– Activate policy:
- sampolicy -a policy.xml
– Deactivate policy:
- sampolicy -d
v Move resources from primary node to standby node.

To move resources from the primary node to the standby node, invoke either of
the following commands:
rgreq –o move –n primary_node_hostname SUT_BASE_TASx
where x is the node ID. Or,

rgreq –o move –n primary_node_hostname CLUSTER_TASx

v To move resources from an offboard media server to the standby node, invoke
either of the following commands:
rgreq –o move –n media _server_hostname SUT_BASE_MediaServerX
where X is the node ID. Or,

rgreq –o move –n media _server_hostname NODE_MGR_MediaServerX
where X is the node ID.
Using the operations console for SAMP monitoring and maintenance:
The IBM Tivoli System Automation Operations Console is the hub for automated
operations and monitoring of applications in a heterogeneous environment.
Normally installed on a separate server, the console is Web-based and designed to
provide easy and efficiently support of the end-to-end landscape. Use of the
operations console for SAMP monitoring is optional.
The SA operations console is a browser-based graphical user interface that is

displayed in IBM Integrated Solutions Console (ISC), which in turn is integrated in
embedded WebSphere Application Server. The console consists of the following
parts:
v An embedded WebSphere Application Server
v Integrated Solutions Console, which runs as an application in the embedded
WebSphere Application Server
v The SA operations console, which is the actual graphical user interface that is
used by operators and administrators for monitoring and managing, runs within
IBM Integrated Solutions Console. The SA operations console itself is displayed
in a web browser.
The SA operations console provides a common console to access all supported

Tivoli System Automation domains. This means, the operator has a console with a
common look and feel to access automated applications running on different types
of clusters; for example, a Linux cluster or an AIX® cluster.
Here is a layout of the main panel of the operations console.

In the top left you can see the domain topology showing clusters and systems,
including a logical automation domain for cross-cluster e-business applications.
This automation domain is called FriendlyE2E in this example and is displayed as
the root of the topology tree.
The selection in the topology tree controls what is shown in the resource table
below the domain topology. The resource table displays the automated resources
for the currently selected domain or node. Currently the automation domain
FriendlyE2E is selected in the topology tree. Therefore the resource table displays
the automated applications that have been defined for the automation domain.
Now, switch back to the end-to-end domain and have a closer look at the
automated e-business applications, below. To get more information about a
particular resource, an operator can select it in the resource table. As the icon
shows, Stock Trading Application is a group that consists of several sub-components
that make up the e-business application Stock Trading Application.

Note the following:
v The resource table now shows the subcomponents belonging to the Stock Trading
Application.
v A breadcrumb trail above the resource table displays the current context
v In the Topology tree Located here column, you can see on which clusters and
systems the components of the Stock Trading Application are distributed.
v The information area shows more details about the currently selected Stock
Trading Application.
Look at the information area on the right side of the screen. The information area
always shows detailed information about the current selection. For example, it
shows the exact name and class, as well as owner information and provides a
hyperlink that can take an operator to further operational information about this
resource. The status section is also important. It shows the currently observed state
of the resource – online, which means that the Stock Trading Application is currently
up and running – and the required state, which is the automation goal that has
been defined in the automation policy. Above these two states the status section
shows summary information, also called a compound state, for the resource. Since
the observed state matches the required state, the summary says that the resource
works as intended and a green icon is displayed.
Installing the SAMP operations console:
Install the IBM Tivoli System Automation for Multiplatforms (SAMP) operations
console.
About this task
Operations console installers are available for Linux and for Microsoft Windows
2003 Server. For detailed instructions, including hardware requirements, see the
SAMP V3.1 Installation and Configuration Guide. The installation steps are
summarized below.
Procedure
1. Open setup.bin.
2. Select the language of the installation.
3. Accept license agreement.

4. Select a destination directory for the installation.
5. Specify a user ID and password for the IBM WebSphere Application Server
administrator.
6. On the next screen, the default ports for the embedded WebSphere Application
Server are shown. If there is no other WebSphere Application Server installation
on this system, select the default ports.
7. Select the user ID, password, given name, and family name of the SAMP
Operations Console administrator.
8. On the next screen, review the information and ensure that it is correct. Then
select the Install button to install the application.
9. Verify the installation by opening a web browser and navigating to the
following URL to display the SAMP Operations Console login page:
http://fully_qualified_host_name:9060/ibm/console
Configuring the SAMP Operations Console:
Configuring the Operations Console consists of a single step.
About this task
Start the configuration dialog. See Chapter 6 of the Installation and Configuration
guide SAMP to get more details.
Procedure
1. Typing either of the following commands will start the configuration dialog for
the Operations Console.
v In Windows, go to (cd) C:\Program Files\IBM\tsamp\eez\bin\ and type the
following command:
cfgdirect.bat
v On Linux, type the following command:
cfgdirect
2. Specify the Event port number on the Server tab. Default port is 2002.
Configuration of the Operations Console is complete.
Configuring the Base Component Automation Adapter of the SAMP Operations Console:
The configuration of the Base Component Automation Adapter is described in

detail in Configuring the end-to-end automation adapter of IBM Tivoli System for
Multiplatforms, Chapter 14.

About this task
In order to directly access the Operations Console, you must configure the
automation adapter of the SAMP Base Component. The end-to-end automation
adapter can be configured with the cfgsamadapter utility.
Note: The automation adapter can be configured from any node in the SAMP
cluster.
Procedure
1. Start the adapter using the cfgsamadapter command. The following dialog
appears.
This screen allows you to do the following tasks:

v Configure the end-to-end automation adapter.
v Replicate the end-to-end automation adapter configuration files to other
nodes.
v Define the end-to-end automation adapter automation policy to create the
resources required to automate the adapter.
v Remove the end-to-end automation adapter automation policy.
2. Click Configure.
a. On the Adapter tab, you can configure the host. Below is a screen capture
of a sample Adapter tab from the Installation and Configuration Guide.

b. For the Host name or IP address field, enter the host name where the
adapter runs if the adapter is not automated. This can be any node in your
cluster. IBM automates the adapter, to make it highly available, so this value
is automatically updated with the value of the Adapter IP address field on
the Automation tab. This value will be updated if the primary node you
specified fails and the adapter fails over to another system in the cluster.
c. Use the default values for the Request Port Number and Event Port
Number.
3. On the Host Using Adapter tab.

a. Select the Configure direct access Operations Console option.
b. Complete the Host Name or IP address field with the name or IP address
of the system on which the Operations Console is running.
c. Use the default 2002 port for Event Port Number. This is the port specified
during configuration of the Operations Console.
4. The next tab to configure is the Automation tab. This tab allows you to
configure the automation adapter automation policy. Performing this task
makes the adapter highly available, meaning if the node on which the adapter
is running fails, then the adapter restarts on another node in the domain. See
the Installation and Configuration Guide for more details.

a. Select the Automate adapter in first-level Automation Domain check box.
b. Click Query Domain
c. Enter the name you want to give to the adapter in the Automated resources
prefix field.
d. Enter the Adapter IP Address with the virtual IP address of one of the
systems in the cluster.
e. Define the cluster netmask with same value specified in the
AutomationPolicyResponsefile.txt.
5. Click Save to save the configuration. After saving the configuration, you will be
returned to the main screen of the automation adapter.
6. Click Replicate to replicate the automation configuration to all the other nodes
in the domain. The following dialog displays. (screen capture is from the
Installation and Configuration Guide.)
a. Select to replicate all the configuration files to all nodes by clicking both
Select all buttons.

Note: When selecting the target nodes, the user ID and Password must be
the same on all if choosing the Select all option. If the nodes have different
user IDs and or passwords, then the files must be replicated to each node
separately.
b. Click Replicate.
After replicating the configuration to the other nodes of the domain, you will
be returned to the main screen of the automation adapter.
7. Click Define. Once the automation policy for the adapter has been defined, it
can be started. The configuration on the Base Component Automation Adapter
is now complete.
Starting and verifying the Operations Console:
This topic describes how the Base Component Automation Adapter is brought
online for the cluster, and how to verify that the cluster is available to administer
from the Operations Console.
Procedure
1. To start the automation adapter, log on to one of the nodes in the cluster and
bring it online using the chrg command
chrg –o online samadapter-rg
2. Check that the adapter is online using the command lssam. The automation
adapter resource group is visible at the bottom of the 'lssam' output. The
output provides the node on which the adapter is currently active.
3. It is now possible to administer the domain from the Operations Console. Log
in to the Operations Console and verify that the cluster is visible.
Starting and stopping services

IBM Lotus Sametime Unified Telephony provides a set of commands for starting
and stopping services on Telephony Application Servers and Telephony Control
Servers.
The Telephony Control Servers can operate on three different levels, with the
runtimes controlled separately from the databases. On Telephony Application
Servers, the IBM WebSphere Application Server and the framework can be
controlled separately. For more information, see the following topics:
TAS runtimes
To start and stop the IBM WebSphere Application Server and the framework on the
Telephony Application Server in an IBM Lotus Sametime Unified Telephony
deployment, issue the following commands.
Procedure
1. To stop or start the WebSphere Application Server, begin by opening up a
terminal on TAS (with Putty) and log in as root user.
2. To start the WebSphere Application Server, run the command #
/opt/IBM/WebSphere/AppServer/bin/startServer.sh server1.
3. To stop the WebSphere Application Server, run the command #
/opt/IBM/WebSphere/AppServer/bin/stopServer.sh server1 -user
WAS_Admin_Username -password WAS_Admin_Password.
4. To check the status of WebSphere Application Server, run the command:
/opt/IBM/WebSphere/AppServer/bin/serverStatus.sh server1 -user
WAS_Admin_Username -password WAS_Admin_Password.

5. To start or stop the framework, open a terminal on TAS (with Putty) and log in
as root user.
6. To start the framework, run the command: # /etc/init.d/framework start.
7. To stop the framework, run the command: # /etc/init.d/framework stop.
8. To check the status of the framework, run the command: #
/etc/init.d/framework status.
TCS runtimes
To change the run level of the TCS server, follow these steps.
About this task
The TCS nodes can operate in one of three different documented levels:
v Level 4: The runtimes and databases are all up and running.
v Level 3: The TCS Runtime (RTT) is down, but the Database remains up.
v Level 2: The TCS Runtime (RTT) and Solid Database are down.
Procedure
1. To alter the run level, first execute the srxctrl command by logging in to a
TCS node as root user and change to the following directory # cd
/unisphere/srx3000/srx/startup
2. Then, execute the srxctrl command. The command to alter the run level of the
TCS nodes takes two arguments: Argument 1, the run level for the local node,
on which the command is being executed and Argument 2, the run-level of the
remote TCS node. The command to alter the run level of TCS is # ./srxctrl 4
4
3. Check the status of the server before leaving the console. Run the command: #
./srxqry
Example
To restart the TCS nodes (both of them) without disrupting service, first, take
down the primary node: # ./srxctrl 3 4. To start the primary node and take
down the secondary node: # ./srxctrl 4 3. To start the secondary node and set
nodes are back at run-level 4 # ./srxctrl 4 4. Here's an example of the output:
-- --- srxqry started on Tue Feb 2 09:05:02 GMT 2010 ---
-- OS : Linux
-- Platform : x3650T
-- Cluster : DUBTCS02
Node name Status
--------- ------
Local Node : dubtcs02node1 Online at state 4
Remote Node : dubtcs02node2 Online at state 4
- Get running applicationsinformation on dubtcs02node1, please stand by...
- Checking for running applicationson dubtcs02node1... -- UCE and all
signaling managers are up and running on dubtcs02node1 Found the
following interfaces configured from RTP configuration!
For Node: dubtcs02node1
CCM 0.5 Vip: 192.168.100.192
Up
CCM 1.0 Vip: 192.168.100.133
Up
CCM TGCP Vip: 192.168.100.199
Up
CSTA Vip: 192.168.100.246
Up
SIP Vip: 192.168.100.236

Up
SIP TLS Auth Vip: 192.168.100.239
Up
- Checking for running applicationson dubtcs02node2...

-- UCE and all signaling managers are up and running on
dubtcs02node2 Found the following interfaces configured
from RTP configuration!
For Node: dubtcs02node2
CCM 0.5 Vip: 192.168.100.194
Up
CCM 1.0 Vip: 192.168.100.159
Up
CCM TGCP Vip: 192.168.100.201
Up
SIP Vip: 192.168.100.238
Up
SIP TLS Auth Vip: 192.168.100.245
Up -- -
-- srxqry ended on Tue Feb 2 09:05:11 GMT 2010 ---
Verifying the installation

Test the configuration of the Telephony Control Server by verifying both TAS and
TCS servers.
Before you begin
You must have performed the initial configuration of the TCS and TAS servers.
About this task
This testing phase checks the health of both TAS and TCS. You can print out the
actual TCS software version. After you have tested the connections and health
status, you can continue to integrate with the customer environment.
Procedure
1. Perform a health check for the TAS. Log in through SSH as root. These tests
verify that TAS can work with TCS and Sametime Server:
a. Test that two connections to the Sametime server on port 1516:
netstat -an |grep 1516.
b. Test that one connection to TCS CSTA is active on port 1040:
Note: The port 1040 will not become actively connected until after the
CSTA connection has been configured in the Common Management Portal
(CMP).
c. Test that one connection to SIP WebsphereProxy is active on port 5060:
d. Test that one connection to the SIP TLS WebsphereProxy on active on port
5061:
e. Test that one connection to SIP Conference is active on port 5070:
f. Test that one connection to SIP TLS Conference is active on port 5071:
2. Print out the TCS software version using the following command: pkgversion
-ps. The output depends on the used patch set and the E-patch level.

3. Perform a health check on the TCS. In a PuTTy session, run startup/srxqry as
the srx user with root rights. You want to verify that all components are started
and node 1 is at status 4 (up and running).
Deploying Lotus Sametime Unified Telephony to users

Before Lotus Sametime Unified Telephony can be deployed to users, they must
have installed the IBM Lotus Sametime Connect client or Lotus Sametime client
embedded in Notes®. This section explains how to enable Lotus Sametime Unified
Telephony for use with Sametime clients.
Preparing the Sametime client

Enable IBM Lotus Sametime Unified Telephony features that are installed with the
Lotus Sametime client.
Procedure
1. Enable Lotus Sametime Telephony features in the Lotus Sametime Connect
client.
Starting with release 8.5.1, telephony features are automatically installed into
the Lotus Sametime client, and you enable the telephony features from the
Lotus Sametime user interface as described in the Lotus Sametime Standard
information center topic, Enabling Sametime Unified Telephony client features.
2. On each Lotus Sametime Community Server in the deployment, edit the
sametime.ini file and specify a limit for the IGNORE_SUBSCRIBES_ABOVE_MAX
setting.
For more information, see the Lotus Sametime Standard information center
topic, Advanced settings to control contact list size.

Chapter 3. Configuring
Configuring an IBM Lotus Sametime Unified Telephony deployment involves a
series of tasks to be completed on different servers in the deployment.
Configuring the Telephony Control Server

This section describes the steps involved in configuring the Telephony Control
Servers. You must configure the connections between the TCS and TAS servers to
create the Sametime Unified Telephony system. This section also explains how to
configure the system-wide parameters.
Command-line interface tasks

Perform these tasks using the command-line interface (CLI).
Setting up remote access for a Telephony Control Server

This section describes how to set up remote access to the Telephony Control Server
in an IBM Lotus Sametime Unified Telephony deployment.
Before you begin
You must have installed the Telephony Control Server cluster.
About this task
The file /etc/security/access.conf on both Telephony Control Server nodes

contain access rules that dictate who can remotely access the system and from
where. After initial installation of the Telephony Control Server cluster, modify this
line as follows to ensure remote access to the nodes.
Procedure
1. Open the access.conf file for editing and locate the following line:
-:root:ALL EXCEPT LOCAL vmtcs1a vmtcs1a_cip0 vmtcs2a vmtcs2a_cip0 console localhost tty1 tty2 tty3 tty4 tty5 tty6 clusternode1-priv clusternode2
2. At the beginning of the line, change the - to + as follows:
+:root:ALL EXCEPT LOCAL vmtcs1a vmtcs1a_cip0 vmtcs2a vmtcs2a_cip0 console localhost tty1 tty2 tty3 tty4 tty5 tty6 clusternode1-priv clusternode2
3. Now locate this line:
-:srx:ALL EXCEPT LOCAL 10.236.11.201 vmtcs1a vmtcs1a_cip0 vmtcs2a vmtcs2a_cip0 console localhost tty1 tty2 tty3 tty4 tty5 tty6 clusternode1-priv
4. Again at the beginning of the line, change the - to + as follows:
+:srx:ALL EXCEPT LOCAL 10.236.11.201 vmtcs1a vmtcs1a_cip0 vmtcs2a vmtcs2a_cip0 console localhost tty1 tty2 tty3 tty4 tty5 tty6 clusternode1-priv
5.
6. Save and close the file.
Setting the GNF replacement prefix

This section describes how to set the GFN replacement prefix by using the CLI
tool.
About this task
In this example, dialing 9 reaches an outside line and dialing 00 reaches an

international number. Where a number is prefixed with a +, it is changed to 900.
Here's how to set the replacement prefix.
Procedure
1. To set the GNF Replacement Prefix, open up putty session to one of the TCS
nodes. To carry out this task use the CLI tool.
2. Log in as srx and execute startCLI.
3. Log in as sysad.
4. At the Main Menu, enter 1.
5. At the Configuration Management menu, select 1.
6. At the Configuration Parameters menu, select 3.
7. At the modifyParameter: prompt, enter hiQ/CSTA/GNFPrefixReplacement.
8. At the modifying variable parameters: prompt, enter ???.
9. At the value <max length 2047>:, enter 900. Then at the input value was:,
enter 900.
10. Enter yes to confirm the action. Then, enter 99 at each menu to exit CLI.
Example
In the following example, user input is shown as highlighted text.

dubtcs02node1:~ # su - srx
srx on dubtcs02node1 using /dev/pts/0 ...
dubtcs02node1:/unisphere/srx3000/srx (140> startCli
RTP Command Line Interface
Copyright (C) Fujitsu Siemens Computers GmbH 1999 - 2010

All Rights Reserved
Copyright (C) 2000-2005 Siemens Network Convergence LLC.

All Rights Reserved.
NOTE: You may use this software only in accordance with the terms of your
license agreement, located on any of the installation CDs for this product.
(This process is running as "RtpAdmCli01")
Login: sysad
Management session established for user "sysad" on "dubtcs02node1"
Main Menu:
Configuration Management.......................1
Fault Management...............................2
Performance Management.........................3
Security Management............................4
System Management..............................5
Application-level Management...................6
Open Logfile............................94
Show Callback Output....................95
Wait for Callbacks......................96
Change Password.........................97
Expert Mode.............................98
Exit....................................99
Selection: 1

Configuration Management:
Configuration Parameters.......................1
Logging........................................2
Return..................................99
Selection: 1
Configuration Parameters (methods):
browseParameterNames...........................1
getParameterInfo...............................2
modifyParameter................................3
createParameter................................4
deleteParameter................................5
loadConfigVersion..............................6
removeConfigVersion............................7
getAllSavedConfigVersions......................8
saveCurrentConfigVersion.......................9
Return..................................99
Selection: 3
modifyParameter:
name : hiQ/CSTA/GNFPrefixReplacement
invariant settings:
name : hiQ/CSTA/GNFPrefixReplacement
type : PARM_STRING
usage : PARM_USAGE_CUSTOMER
lastUpdateMillis : 25.Nov.2009 19:29:19h (000 msec)
changeId : 0
descriptionString:
modifying variable parameters:
current value: ???
value <max length 2047>: 900

input value was: "900"
Do you want to execute this action? (default: yes): yes
Enabling SIP session timers

In order for the Telephony Control Server to detect lost calls and therefore avoid
hanging connections, enable the SIP Session Timers in an IBM Lotus Sametime
Before you begin
Turn on the endpoint rerouting.
About this task
SIP session timers prevent the Telephony Control Server from hanging connections
when a call is lost.
Procedure
1. Log in as sysad.
Chapter 3. Configuring 131

2. Execute startCLI. From the Main menu, select Configuration Management.
Select 1.
3. Select 1 to select Configuration Parameters.
4. Select 3 to select modifyParameter. Change the settings as follows:
a. name: Srx/Sip/Session_Timer
b. Invariant settings:name : Srx/Sip/Session_Timer
type : PARM_STRING
lastUpdateMillis : 13.May.2009 09:44:20h (000 msec)
changeId : 0
descriptionString:
c. modifying variable parameters:
current value: NO
value <max length: 2047>: YES
input value was: "YES"
Do you want to execute this action? (default: yes)
5. Follow the same method to set Srx/Sip/ZeroIpOnHold to the value 0.
6. Now set Srx/Main/UseSendOnlyForMOH to the value RtpTrue.
Enabling a timer for the unified number service

This timer defines how much time the TCS will wait after offering the call to the
TAS before it deflects the call to the dependable target.
About this task
When a call is received, the TCS sends the call to the TAS and within milliseconds
the TAS deflects the call to the target that is the outcome of the rules/routing
workflow engine. If there is a problem on the TAS, the TCS will deflect the call to
the dependable target after an interval defined by the timer. During high load
periods, the default 2 seconds can be too short, resulting in a deflection to the
dependable target just before a normal deflection to the correct target. Moving the
timer to 3 seconds makes deflection to the correct target more likely.
Procedure
2. Log in as sysad.
3. At the Main Menu, enter 1.
6. At the getParameterInfo prompt, enter hiQ/CSTA/DelayAtONSOfferedState.
7. Press Enter to continue.
9. At the createParameter: name <max length: 255> : prompt, enter
hiQ/CSTA/DelayAtONSOfferedState.
10. At the usage <PARM_USAGE_CUSTOMER 2> (default: 2) field, select 2.
Then choose yes when asked, Do you want to execute this action? (default:
yes.
11. At the Configuration Parameters menu, select 2. At the name (default: ):,
enter hiQ/CSTA/DelayAtONSOfferedState

14. At the Main Menu, select 5.
15. At the System Management menu, select 1.
16. At the Process & Node (methods), select 8.
17. After the stopProcess: prompt, at the logicalName: prompt enter uce1. Then
execute the action.
18. At the Process & Node (methods), select 6.
19. After the startConfiguredProcess: at the logicalName:prompt, enter uce1
20. Repeat steps 16 — 19 substituting uce2, uce3 and, finally, uce4.
Example
dubtcs02node1:~ # su - srx
srx on dubtcs02node1 using /dev/pts/0 ...

All Rights Reserved

NOTE: You may use this software only in accordance with the terms of your
license agreement, located on any of the installation CDs for this product.
(This process is running as "RtpAdmCli01")
Login: sysad
Main Menu:
Open Logfile............................94
Change Password.........................97
Expert Mode.............................98
Exit....................................99
Selection: 1
Logging........................................2
Return..................................99
Selection: 1


Return..................................99
Selection: 2
getParameterInfo:
name (default: ): hiQ/CSTA/DelayAtONSOfferedState
executing method getParameterInfo...
The following error situation has occurred:

The given configuration parameter could not be found in the database.
(nativeGetParamRecord/RtpCfgGetParamRec:
szName=hiQ/CSTA/DelayAtONSOfferedState RtpErrno:EDBINORECORD)
Do you want to see more details? (default: no):

Display Class Name......................98

Return..................................99
Selection (default: 2): 4
createParameter:
name <max length: 255> : hiQ/CSTA/DelayAtONSOfferedState

type <PARM_INT: 0, PARM_FLOAT: 1, PARM_STRING: 2, PARM_DIGITS: 3,
PARM_BOOL: 4,PARM_POINTCODE: 5, PARM_DATE: 6, PARM_IP: 7, PARM_BINARY: 8>
(default: 0):
value <max lenth: 2047>: 3000
usage <PARM_USAGE_CUSTOMER 2> (default: 2):
descriptionString (default: ):
valueDescriptions[0].valueTitle <end: "."> (default: .):
Do you want to execute this action? (default: yes):
executing method createParameter...
Ok.
Press <Return> to continue

Return..................................99
getParameterInfo:
name (default: ): hiQ/CSTA/DelayAtONSOfferedState
executing method getParameterInfo...
Ok.
Parameter Information:
name : hiQ/CSTA/DelayAtONSOfferedState
value : 3000
type : PARM_INT
lastUpdateMillis : 20.Mar.2009 09:14:25h (000 msec)
changeId : 0 descriptionString:


Return..................................99
Logging........................................2
Return..................................99
Main Menu:
Open Logfile............................94
Change Password.........................97
Expert Mode.............................98
Exit....................................99

System Management:
Process & Node.................................1
Subsystems.....................................2
Tickets........................................3
SW Installation................................4
Return..................................99
Selection: 1
Process & Node (methods):

getProcessInformation..........................1
getAllProcessStatus............................2
configureProcess...............................3
modifyProcessConfiguration.....................4
deleteProcess..................................5
startConfiguredProcess.........................6
startProcess...................................7
stopProcess....................................8
createProcessGroup.............................9
modifyProcessGroup............................10
deleteProcessGroup............................11
getProcessGroupInformation....................12
getNumberOfProcessGroupMembers................13
startProcessGroup.............................14
stopProcessGroup..............................15
getAliasInformation...........................16
createAlias...................................17
modifyAlias...................................18
deleteAlias...................................19
getCeInformation..............................20
getAllProcessGroupStatus......................21
getAllConfiguredProcessGroups.................22
restartProcess................................23
Return..................................99
Selection: 8
stopProcess:
logicalName: uce1
executing method stopProcess...
Ok.

deleteProcess..................................5
startProcess...................................7
stopProcess....................................8

createAlias...................................17
modifyAlias...................................18
deleteAlias...................................19
restartProcess................................23

Return..................................99
startConfiguredProcess:
logicalName: uce1
executing method startConfiguredProcess...
Ok.
deleteProcess..................................5
startProcess...................................7
stopProcess....................................8
createAlias...................................17
modifyAlias...................................18
deleteAlias...................................19
restartProcess................................23

Return..................................99
stopProcess:
logicalName: uce2
Ok.

deleteProcess..................................5
startProcess...................................7
stopProcess....................................8
createAlias...................................17
modifyAlias...................................18
deleteAlias...................................19
restartProcess................................23

Return..................................99
logicalName: uce2
Ok.
deleteProcess..................................5
startProcess...................................7
stopProcess....................................8
createAlias...................................17
modifyAlias...................................18
deleteAlias...................................19
restartProcess................................23

Return..................................99
stopProcess: logicalName: uce3
Ok.
deleteProcess..................................5
startProcess...................................7
stopProcess....................................8
createAlias...................................17
modifyAlias...................................18
deleteAlias...................................19
restartProcess................................23

Return..................................99
logicalName: uce3
Ok.
deleteProcess..................................5

startProcess...................................7
stopProcess....................................8
createAlias...................................17
modifyAlias...................................18
deleteAlias...................................19
restartProcess................................23

Return..................................99
stopProcess: logicalName: uce4
Ok.

deleteProcess..................................5
startProcess...................................7
stopProcess....................................8
createAlias...................................17
modifyAlias...................................18
deleteAlias...................................19
restartProcess................................23

Return..................................99
logicalName: uce4

Ok.

deleteProcess..................................5
startProcess...................................7
stopProcess....................................8
createAlias...................................17
modifyAlias...................................18
deleteAlias...................................19
restartProcess................................23

Return..................................99
Selection (default: 6):
Changing the TCS root password

For security, the default password on the TCS must be changed.
Procedure
1. To change the TCS root user password, log in to each TCS node and enter the
passwd command to change the root password.
2. Once you enter the command, you will see the following:
Changing password for root.
You can now choose the new password.
A valid password should be a mix of upper and lower case letters,

digits, and other characters. You can use an 8 character long
password with characters from at least 3 of these 4 classes.
An upper case letter that begins the password and a digit that
ends it do not count towards the number of character classes used.
Enter new password:
Re-type new password:
Password changed
Note: Use the same password on both TCS nodes and change passwords at
the same time on both TCS nodes

Allowing TCS access for offboard Media Server (optional)
In order to enable the communication between the Telephony Control Server and
offboard Media Servers, you must create packet filter rules.
About this task
You can create the packet filter rules to enable communication between the
Telephony Control Server and the offboard Media Server.
Procedure
2. Log in as sysad.
3. Starting at the Main menu, select 6 > 8 > 4 > 1. Then, add the following
parameters:
Packet Filter Rule Name <Max length:63 (max length:63)> default: ):
Packet Filter Name
Description <To clear enter /000 (max length:63)> (default: ):
Packet Filter Name Description
Remote FQDN <To clear enter /000 (max length:63)> (default: ):
Press <enter>
Remote IP Address <To clear enter /000 (max length:15)> (default: ):
<Media Server IP address>
Remote Netmask <To clear enter /000 (max length:15)> (default: ):
<Media Server subnet mask>
Transport Protocol <1 = icmp, 2 = udp, 3 = tcp, 4 = all, 5 = esp,

6 = ah, 7=sctp>: <enter 2 for udp or 3 for tcp>
Remote Port Begin <0 = All Ports>: 0
Direction <1 = incoming, 2 = outgoing, 3 = both ways>: 3
Local Host: <To clear enter /000 (max length:32)> (default:) :
<TCS IP address>
Local Port Begin <0 = All Ports>: 8767
Local Port End <0 = Only Begin Port is Valid>: 0
Action <1 = Allow, 2 = Drop>: 1
Do you want to execute this action? <y/n> (default:yes):yes

Operation Successful
Press <Return> to continue.
In a cluster Telephone Control Server, the Packet Filter Rule must be added
three times for each of the three Telephony Control Server IP addresses, such as
the physical IP address of node1, physical IP of node2, or the virtual IP.
4. Verify that the Packet Filter Rule has been accepted by typing 4 from the
Packet Filter Rules Security Management (methods) menu. Then, enter the
packet filter name you have created.
CMP (Common Management Portal) configuration tasks

The CMP (Common Management Portal) is divided into sections where you can
configure and administer IBM Lotus Sametime Unified Telephony servers. CMP
help is available only in English, even when the selected language is German.
The CMP is divided into three main sections: Operations & Maintenance,
Telephony Control Server, and Users & Resources.
Operation & Maintenance
The Operations & Maintenance tab consists of four subsections:

v Diagnostics: contains information regarding Telephony Control Server alarms
used for troubleshooting.
v Configuration & Monitoring: enables configuration of the Media Servers
relevant to a selected Telephony Application Server. This section also enables
configuration of the connection between a Telephony Control Server and the
CSTA to control and monitor telecommunication activities on SIP endpoints.
v Recovery: allows you to perform a backup or restore of the domain
configuration, and perform a mass provisioning of users.
v License Management: allows you to active product licenses and track license
IDs.
The Telephony Control Server tab consists of four subsections:

v General: enables the creation of a connection to the Telephony Control Server by
adding a switch that contains information such as the IP addresses of the duplex
TCS nodes.
v Administration: allows the configuration of Media Servers for tones,
announcements, and languages. Additional provides functions such as Signaling
Management and Licensing Management.
v Business Group: lists all business groups defined for a Telephony Control
Server, enabling you to define Destinations, Endpoints, Routes, and PACs.
v Global Translation and Routing: enables the configuration of interbusiness
group call routing, providing commonly used functions such as:
– Defining office codes
– Defining home DNs
– Defining routing areas
– Defining origin destinations
Users & Resources
The Users & Resources tab allows you to provision users and resources. This
section has three subsections:
v Domain: allows you to define domains for use with the Telephony Application
Server.
v Users: allows you to provision users.
One or more profiles or resources can be assigned to each user. The profiles are
used to assign specific features and access rights to a user. In addition to the
users of the selected domain, you can create foreign users: external users or
administrators from another domain who are to receive specific rights in the
selected domain. Profiles can be assigned from the selected domain to these
foreign administrators for this purpose. Profiles from the other domain cannot
be assigned. It is not possible to assign resources to foreign users.
v Resources: contains information about TCS Resources, such as office codes and
extensions, as well as containing information about Media Server resources for
example SIP Domains, and Conference Devices.
Adding a Telephony Control Server to the CMP

In an IBM Lotus Sametime Unified Telephony deployment, the Telephony Control
Servers and the Telephony Application Servers are administered from the CMP

(Common Management Portal). The CMP is located on the Telephony Application
Server and must be configured to communicate with the Telephony Control
Servers for administration tasks.
Before you begin
To complete this task you need:

v Single Telephony Control Server: The IP address the TCS (node_1_ip from the
node.cfg file).
v Cluster: The virtual IP address of the TCS cluster (nmc_vip from the node.cfg
file).
Procedure
1. On the Telephony Application Server, start the CMP:
a. Open a browser.
b. Enter the URL of the Telephony Application Server's CMP:
https://TAS_URL/management
For example:
https://tas01.example.com/management
c. Log in with the administrator@system.com user name and password.
2. Click Telephony Control Server > General > List of Switches > Switches.
3. Click the Add button.

4. In the Add Switch dialog box, complete the "Connection Settings" section:

Option Description
Name v If you are connecting to a single TCS, type
a descriptive name (for example, you
could use the node's short host name).
v If you are connecting to a cluster of TCS
nodes, leave the Name field blank.
Use cluster name If you are connecting to a cluster of TCS
nodes, click this option to have the cluster's
name filled in automatically.
IP address v Single Telephony Control Server: The IP
address of the TCS (node_1_ip from the
node.cfg file).
v Cluster: The virtual IP address of the TCS
cluster (nmc_vip from the node.cfg file).
srx password Type the srx password (by default the
password is set to srx1srx).
Synchronization will start Leave this set to the default value of As
scheduled by system.
5. Click the Test Connection button to verify that the CMP can connect to the
Telephony Application Server (or cluster).
If the test fails, check the network. If the Telephony Application Server is
operating on a different subnet from the management subnet, then configure

the network so that the TAS can connect freely across the subnets. Add the IP
addresses for the Telephony Control Server nodes to the hosts file on the TAS
(located at /etc/hosts).
6. When the connection passes, click the Save buttonto add the Telephony Control
Server to the CMP. The new TCS (or cluster) appears in the list of switches.
Creating CSTA Link

In order to allow an IBM Lotus Sametime Unified Telephony deployment's
Telephony Control Server to communicate with a Telephony Application Server to
resolve the preferred device on which to redirect an incoming call, a CSTA
connection must be established between both servers.
About this task
CSTA is used for all telephony event-related communications. Without this

connection, the Telephony Control Server routes the call to an SUT user's Call
Forwarding Dependable Target. If calls are mistakenly forwarded to the
dependable target regardless of the preferred device set on the client, then the
likely problem is with the CSTA connection.
Procedure
1. In the CMP, click Operation & Maintenance > Configuration & Monitoring >
System Status > Applications.
2. Create a Media Server Connection:
You only need to add this connection when the Media Server is installed on a
separate computer from the Telephony Application Server (for example, in a
medium-scale deployment).
a. In the System Status table, select the Telephony Application Server, click the
arrow at the end of that row, and click on Media Server connection.
b. In the Media Server Connections dialog box, click the Add button
c. In the Media Server Connection Cluster dialog box, click the Add button.
d. In the Media Server Connection dialog box, fill in the information to define
the connection, and then click OK.

e. Close the remaining dialog boxes and return to the System Status table.
3. Configure the Media Server connection:
a. In the System Status table, click the right arrow next to the Telephony
Application Server, and then click Media Server Configuration.
This task is required regardless of where the Media Server is installed.
b. In the List of nodes dialog box, select the node where the Media Server is
installed, and click the Edit button.
c. On the Providers tab of the Physical node administration dialog box, click
IP Telephony (SIP), and then click the Edit button.
d. In the SIP configuration dialog box, fill in the SIP server's settings, and then
click Save.

e. Close the remaining dialog boxes.
4. You can verify the connection by opening up a putty terminal to your TAS
server and as root user executing the following command:
tas1:~ # netstat -an | grep 1040 tcp
The IP address you used to create the CSTA connection is displayed followed
by the word: ESTABLISHED; for example:
0 0 192.168.2.201:56255 192.168.2.115:1040 ESTABLISHED
Enabling PAC Rerouting

To automatically fail over between routes in a destination when a route is not
responsive to SIP requests in an IBM Lotus Sametime Unified Telephony
deployment, the endpoint rerouting feature must be enabled on the Telephony
Control Server.
Procedure
1. Click Telephony Server > Administration > Signalling Management > SIP.
2. In the SIP Settings dialog box, click the Rerouting tab.
3. In the Rerouting sesction, click the Enable Rerouting for SIP Subscribers check
box, and then click Save.

Configuring announcements
In an IBM Lotus Sametime Unified Telephony deployment, the Media Server
supports conference calls and serves announcements.
A Telephony Control Server can support up to 100,000 users while a Telephony

Application Server supports up to 15,000 users. For any system in full production,
there are multiple Telephony Application Servers operating with a single
Telephony Control Server. Each Telephony Application Server must be paired with
a Media Server). A Media Server serves the announcements for its users. However,
if a Media Server fails, the fail over feature enables another Media Server to
support users until the faulty system is restored.
The Media Server comes with over 300 announcements. When the Telephony
Control Server requests an announcement from a Media Server, it uses an MGCP
endpoint for the Media Server, which must be configured.
Consider the example of a Telephony Application Server and Media Server in

Ireland, with another pair in Scotland, and still another pair in England. There are
three Media Servers and three groups of users. First, it is important to know what
users and what other endpoints (such as local PBXes, the IBM WebSphere
Application Server SIP Proxy, or a Conference bridge), are served by which Media
Server.
Tag the user and endpoints with a routing area object. Prefix the routing areas with
“RA” and then an identifier, for example, for the Irish users it could be “RA_IRL”,
while for Scottish users it might be “RA_SCOT".

The anatomy of an intercept
On the Telephony Control Server there are 349 intercepts, also called
announcements. The intercepts can be viewed in the CMP by clicking Telephony
Control Server > Administration > Media Servers > Intercepts. Within each
intercept, one or more treatments can be applied. A treatment is a pointer to a
wave file and also defines which destination can be used to access the resource.
Pooling intercepts across multiple Media Servers
When configuring intercepts, the treatments can point to a single destination,

which in turn points to an actual Media Server. But this method would use
resources inefficiently. All users and endpoints, no matter what Telephony
Application Server they are part of, would use the same Media Server. Regardless
of the number of Telephony Application Server servers installed, configure
announcements by using the Origin Destination, which supports intercepts across
multiple Media Servers. An origin destination is a container where you can add
origin routes. Each of these routes couples a routing area to a real destination. So
the intercept points to the origin destination, and the origin destination has one or
more entries that couple a routing area to an actual destination.

Announcement destinations
The destination facilitates using a back-up Media Server in case the local Media
Server fails. In Lotus Sametime Unified Telephony, a destination and an endpoint
are created and then joined with a route. There is always one destination
containing one route, which points to one endpoint. For announcement
destinations, create multiple routes, and give each one a priority number, which is
referred to as the ID Number (the lower the ID, the higher the priority). It is
always a good idea to start with a low priority, and work higher. That way, if a
Media Server is taken offline, it is possible to add another Media Server and set it
to a higher priority without interruption.
For example, suppose you have two Media Servers: one located in Ireland and the
other in Germany. When the Telephony Control Server requires an announcement,
the intercept is pointed to the Origin Destination. It uses routing areas on that
object, and routes the request to the MS DE destination. This destination in turn
routes to both the MS_ANN_DE and MS_ANN_IRL servers; however because the
MS DE destination specifies that the MS_ANN_DE has priority, it routes to that
server first. If a failure occurs, the Irish Media Server continues to provide the
announcements to German users and endpoints but treats them as a lower priority.
Creating the media server announcements endpoint:
Create an endpoint for the Media Server announcements in an IBM Lotus

About this task
Lotus Sametime Unified Telephony uses the MGCP (Media Gateway Control
Protocol) for routing announcements. Create a Media Server endpoint that uses
MCGP to serve as a destination for announcements.

Procedure
1. Click Telephony Control Server > Administration > Media Servers > Media
Servers.
2. In the list of Media Servers, click the Add button.

3. In the Add Media Server dialog box, click the General tab and fill in general
settings for the Media Server:

Option Description
Gateway Name Type a name for the new Media Server
endpoint; include "MGCP" in the name.
Fully Qualified Domain Name Type a fully qualified domain name or the
server's IP address enclosed in [ ].
Assign Method Set the method to Automatic.
Protocol Type Set the protocol type to MGCP
Protocol Version Set the version to MGCP 1.0 NCS 1.0.
Circuit format Type $/$ as the format.
Multi Homing Set multi homing to Disabled.
MG Signaling IP Address Allocation Select DNS Query for the IP address
Method allocation method.
MG Signaling Type the same fully qualified domain name
or IP address that you entered in the Fully
Qualified Domain Name field; this time an
IP address does not have to be enclosed in
square brackets.
4. Click the Extended tab, set the DTMF to Enabled, and leave the remaining
settings alone.

5. Click the Circuits tab, the Add button, fill in Circuits settings, and then click
OK.

Option Description
Circuit ID Type ann/$ as the ID.
Circuit End Id Leave this field blank.
Circuit Type Select Announcement.
The circuit tab reflects the new circuits.
6. Click Save to save the MGCP endpoint. It displays on the Media Servers list, as
a blocked object.

7. Next, unblock the MGCP endpoint by clicking the check box for the endpoint
and then selecting the Unblock button.
Creating an announcement destination:
In an IBM Lotus Sametime Telephony Deployment, create a destination with routes

pointing to a Media Server end point, so that announcements can be delivered
across the MGCP network.
About this task
The MGCP (Media Gateway Control Protocol) is a system of media gateways used
to bridge networks; each media gateway acts as an interface between a VoIP (Voice
over Internet Protocol) network and a classic telephone network. To ensure that
announcements can be delivered across the MGCP, you must create a Destination
that contains at least one route pointing to a Media Server within the MGCP
network. Most systems have multiple Telephony Application Servers and Media
Servers, so a destination will typically have two or three routes to other Media
Servers.
Announcements are a global service common to all business groups and

numbering plans, so announcements, and their destinations, are created in the
Telephony Control Server's "Global Translation and Routing" section, and then
stored within the global numbering plan.
Procedure
1. On the Telephony Control Server, start CMP:
a. Open a browser and navigate to: https://TAS_URL/management/.
For example:https://tas01.example.com/management
b. Log in using the administrator@system.com credentials.
2. Click Telephony Control Server > Global Translation and Routing >
Destinations and Routes > Destinations.

3. On the Destinations list, click the Add button.
4. In the Add Destination dialog box's General tab, type a descriptive name for
the new destination, click the is a media server check box; then click Save.
Note: You must save the destination before you can add a route to it in the
next step.
The new destination now appears in the list on the Destinations list.
5. Click the new destination, which opens the Edit Destination dialog box.
6. Click the Routes tab, and then click the Add button.

7. In the Add Route dialog box, fill in the following fields:

Table 5. Fields to set on the "Routes" page
Field Description Recommended value
ID A numeric value If you plan to add another route that will
indicating the priority of be a higher priority, assign this value a low
this route, where "1" number, such as 10, so that you do not
represents the highest have to modify it later when the newer
priority. route is added.
Type The type of server being Select MGCP Media Service from the list.
defined as the end point.
MGCP Media The name of the server Click the . . . button next to the field, select
Service that will function as the the appropriate Media Server, and click
end point for this OK.
destination. Note: Be sure to select the circuit ending in
.ann/$.
The selected server now appears in the MGCP Media Service field.
8. Leave the remaining fields on the page unchanged (be sure to leave the
Signaling Type as Undefined) and click OK.
The new route now appears on Routes list.
9. Click the Routes List tab.

10. Click the Prioritized check box, and then click Save.

When a second route is added and assigned a priority, the routes are chosen
according to their assigned priorities. If you do not select the Prioritized
option and you add routes, the routes will be chosen round robin style (each
route is selected in turn).
What to do next
Now that the destination has been defined, create a routing area as explained in
the next task.
Creating a Routing Area:
If your IBM Lotus Sametime Unified Telephony deployment includes multiple

Telephony Application Servers, a routing area must be created for each Media
Server. Routing areas are assigned to the Unified Numbers and the Endpoint
Profiles to allow for load balancing for Media Server tones and announcements.
Before you begin
Before you create the routing area, define ssign the Media Server's unified numbers
and endpoint profiles.
Procedure
Translation > Routing Areas.

3. In the Add Routing Area dialog box, type a descriptive name for the routing
area in the Name field. In this example, the Telephone Application Server is
assigned to Ireland is solely for use in Ireland, so it is named RA_IRL.
4. Click Save.
5. Add a routing area for each Media Server.
Creating an origin destination:
An origin destination links a routing area to a destination for all intercepts

associated with that origin destination in an IBM Lotus Sametime Unified
Telephony deployment.

About this task
Only one origin destination is needed for the deployment, even when you use
multiple Telephony Application Servers and Media Servers.
Procedure
Destinations and Routes > Origin Destinations.
3. In the Origin Destinations dialog box, type a descriptive name in the Name
field, and then click the Save button.
The new origin destination appears in the Origin Destinations list.

4. Click the check box in front of the newly created origin destination to select it,
and then click the Edit button.

5.
6. In the Origin Destinations dialog box, click the Routes tab, and then click the
Add button.
7. In the Origin Route dialog box, click the button next to the Routing Area
field, select a routing area from the list, and then click OK.

8. Back in the Origin Route dialog box, leave the Destination Type set to
Destination.
9. Click the button next to the Destination Name field, select a destination, and
then click OK.

10. Back in the Origin Route dialog box, click OK to save the new origin route.
11. Back in the Origin Destinations dialog box, the new origin destination
appears; now click Save to save it.
Enabling media server failover:
Enable auditing to ensure that the Telephony Control Server is checking for failures
and making use of other Media Server MGCP routes as needed in an IBM Lotus
Procedure
1. Click Telephony Control Server > Administration > Media Servers > Media
Server Audit.

2. In the Media Server Audit dialog box, Click the Automatic Audit On check
box, and then click Save.
Applying Treatments:
Treatments are for localizing announcements; you can apply treatments with a
script that is provided with IBM Lotus Sametime Unified Telephony. The msconf.sh
script lets you assign the treatments of all known intercepts of the Telephony
Control Server to an origin destination.
Before you begin
To assign treatments with the Modify_Treatments.sh, an origin destination must

have been created already in the Telephony Control Server, and its name must be
known.
About this task
The msconf.sh script creates an ASK_ME intercept type that can be used to play
ringback in the queue device. It is different from the RINGBACK_TONE intercept
because the ASK_ME intercept answers the call before playing the intercept. The
msconf.sh script can also unassign the treatments from all known intercepts of the
TCS.

At installation, the following files are copied to the /tmp directory of the TCS:
msconf.sh, Assign_Treatments.txt, Unassign_Treatments.txt.
Procedure
1. Assign the proper execute rights to the msconf.sh script:
/tmp# chmod 744 msconf.sh.
2. Go to the /tmp directory and run the following command:
/tmp# ./msconf.sh
3. The script asks the following questions:
1) What do you want to do? Assign or Unassign treatments? [1 | 2]
-->1.1) Please give the name of the origin destination [max 15 characters]
------->1.1.1 Do you want to assign the treatments now? [y/n]
-->2.1) Do you want to unassign the treatments now? [y/n]
4. When you answer Y to the last question, the script starts running. At the end, a
report is offered that indicates whether the script executed:
CLI>stty: standard input: Inappropriate ioctl for device
The procedure is finished.
Report:
Treatments are assigned.
5. When the script is finished, check whether the script actually performed its
task. The output contains the following lines:
********* Treatment Request Response Message *********
Created treatment AOCBEnterProg(976)[1] in the database and shared memory
If the origin destination was not yet created in the TCS, the following line
would appear instead:
********* Treatment Request Response Message *********
Cannot find origin destination </ORIG_DEST_MS> in the database
.
6. If the msconf.sh script does not execute and the proper execute permissions are
set on the script, then run the command from the /tmp prompt:
/tmp# dos2unix msconf.sh
7. Check Intercepts in CMP and look at the last page for ASK_ME. Consider
Optimizing call interception for billing.
Configuring Telephony Application Servers

Configure the TAS server, including the proxy application, registrar application,
WebSphere Application Server SIP proxy access, the SIP proxy registrar
applications, and activate the SIP container.
Initializing the persistent cache on a Telephony Application

Server
Choose a method for initializing the persistent cache on a newly installed
Telephony Application Server in the IBM Lotus Sametime Unified Telephony
deployment.
Before you begin
The Telephony Presence Adapter is a component running on the Telephony

Application Server. This adapter is based on the Lotus Sametime Java Toolkit
TelephonyAdapter component, and is used to relay presence information back and
forth between a Lotus Sametime server and a Telephony Control Server. An

unrecognized user name is passed from the Telephony Control Server to the Java
toolkit residing on the Telephony Application Server, which forwards it to the
Lotus Sametime Community Server for resolution; the resolved name is used by
the ST Community for watching on the user's Sametime status as well as for
publishing user's telephony status.
Managing presence information requires the Telephony Presence Adapter to

resolve unified telephony users against the Lotus Sametime community. Whenever
you start a Telephony Application Server, it must resolve all of the Lotus Sametime
Unified Telephony users in the deployment. Because the deployment can serve a
large number of users, this process may require a lot of system resources. For
example, if the Lotus Sametime Unified Telephony deployment services 15,000
users, it may take 40 minutes to resolve all of the user names. To decrease this
load, the Telephony Presence Adapter utilizes a persistent cache, where it stores
information about resolved user names for later re-use.
Set up and initialize the persistent cache once for each Telephony Application
Server, and then refresh each persistent cache as needed (usually whenever user
records are updated in the LDAP directory).
About this task
Initialize the cache after a new Telephony Application Server installation, after you
have started the TAS for the first time. The cache initialization may cause a high
load on both the Telephony Application Server and the Lotus Sametime server
because it must resolve all users in the unified telephony deployment, so you
should plan this task for a time when the deployment is in low demand.
Note: Initialize the persistent cache on every Telephony Application Server in the
deployment, except the failover nodes. In a failover environment, the persistent
cache may be copied from the failed server to the backup server (assuming that at
least the latest persistent cache version is stored on disk). Then if the server fails
before it has flushed the most recent cache additions to disk, the previous
persistent cache can be used; remember that if the mostly recently resolved names
had not been stored to disk, this version of the persistent cache will be missing
those names).
There are two methods for initializing the persistent cache; you only need to
complete one of these tasks:

Initializing the persistent cache using Telephony Presence
Adapter settings
In an IBM Lotus Sametime Unified Telephony deployment, initialize a Telephony
Application Server's persistent cache in chunks by resolving a specified number of
user names at a time.
About this task
The Telephony Presence Adapter can be configured to send resolve request in

chunks, so that a specified number of user names are resolved, then a delay occurs
before the next chunk of names are resolved. This method reduces server load by
allowing time for other tasks to be completed between chunks. The number of user
names to be resolved in each chunk, and delay between chunks, are defined in the
user.presence.adapter.properties configuration file:
Procedure
1. On the Telephony Application Server, open the /enterprise/ibm/
user.presence.adapter.properties file for editing (leave the server running).
2. Locate the following section in the file, and specify the chunk size (the number
of names to resolve in one pass) and the delay (in milliseconds) as shown:
###############################
# Description - The number of resolve requests to send at each chunk
# Value - The number of requests.
# Default value - 1000 requests
###############################
resolve.chunk.size=1000
###############################
# Description - The time to wait between chunks of resolve requests.
# Value - time interval in milliseconds
# Default value - 1 minute
###############################
resolve.chunk.delay=60000
In this example, the Telephony Presence Adapter sends 1000 resolve requests at
a time, and then waits for 1 minute (60000 milliseconds) before sending another
chunk of names. If 15000 users are provisioned on the Telephony Application
Server, the cache initialization will take approximately 15 minutes.
4. Restart the Telephony Application Server.
5. Once the cache has been initialized, edit the file again and reset the chunk size
to 15000 names and the delay to 10 milliseconds.
From now on, the cache will be initialized from the persistent cache and will
require much less time to process, so it is safe to lower these settings.
6. Repeat this process for every Telephony Application Server in the deployment,
except for failover servers.
Initializing the persistent cache with the Java Toolkit

CachedResolveBatchMode application
In an IBM Lotus Sametime Unified Telephony deployment, initialize a Telephony
Application Server's persistent cache using the Java Toolkit
CachedResolveBatchMode application.
About this task
The 8.5.1 Sametime Java Toolkit CachedResolve component provides the

CachedResolveBatchMode application, which is designed to create the initial

persistent cache by loading user names from a text file and resolving them against
the Lotus Sametime server. To avoid a load on the server, the
CachedResolveBatchMode application sends requests in configurable chunks.
Procedure
1. Configure the initial provisioning on the TAS, as explained in Initial
provisioning, in the Lotus Sametime Unified Telephony Administration
information center.
2. Now run the initial provisioning on that server.
3. Next, run the create_user_list.sh script to convert the provisioning output
file to a format that can be used for resolving user names with the Lotus
Sametime server:
/enterprise/ibm/tools/create_user_list.sh input_file.CSV output_file.TXT
where:
v input_file.CSV is the path and name of the CSV file that was generated when
you ran the initial provisioning.
v output_file.TXT is a name you assign to be used for storing the converted
names from the input file; this file will be stored in the current directory.
For example:
/enterprise/ibm/tools/create_user_list.sh /opt/IBM/tivoli/tdi/solutions/SUT/output/abc.csv users.txt
The output file generated by this script will look like this:
user10@hades.com
user11@hades.com
user12@hades.com
user13@hades.com
4. Start the Lotus Sametime server where you want to resolve users.
5. On the Telephony Application Server, run the init_resolve_cache.sh script to
activate the CachedResolveBatchMode application and resolve the user names
in the new file:
/enterprise/ibm/tools/init_resolve_cache.sh community_name external_users_file chunk_size chunk_delay_in_ms
where:
v community_name is the name of the Lotus Sametime community hosted on
the server that will resolve the user names.
v external_users_file is the full path and name of the output file generated in
step 3 above (called "users.text" in the example), which contains the names to
be resolved.
v chunk_size is the number of names to resolve in one pass.
v chunk_delay_in_ms is the amount of time (in milliseconds) to wait before
submitting another chunk of names to be resolved.
6. Start the Telephony Application Server and allow the persistent cache to be
initialized.
7. After the persistent cache is initialized, modify the Telephony Presence Adapter
and set the chunk size to 15,000 names and the delay to 10 milliseconds.
From now on, the cache will be initialized from the persistent cache and will
require much less time to process, so it is safe to lower these settings.
a. Open the /enterprise/ibm/user.presence.adapter.properties file for
editing.
b. Locate the following section in the file, and specify the chunk size (the
number of names to resolve in one pass) and the delay (in milliseconds) as
shown:

###############################
# Description - The number of resolve requests to send at each chunk
# Value - The number of requests.
# Default value - 1000 requests
###############################
resolve.chunk.size=15000
###############################
# Description - The time to wait between chunks of resolve requests.
# Value - time interval in milliseconds
# Default value - 1 minute
###############################
resolve.chunk.delay=10
c. Save and close the file.
8. Repeat this process for every Telephony Application Server in the deployment,
except for failover servers.
Establishing trust between Telephony Application Servers and

Lotus Sametime servers
Every Telephony Application Server in the IBM Lotus Sametime Unified Telephony
must be designated as "trusted" before it can communicate with a Lotus Sametime
server. Establish trust by adding a TAS server's IP address to the Lotus Sametime
server. If you do not want the TAS to communicate with a particular Lotus
Sametime server, you can add that Lotus Sametime server to the “exclusion" list on
that TAS.
Before you begin
Whenever you install a server that communicates with a Lotus Sametime server,
you must add the new server's IP address to the Lotus Sametime server's
“Community Trusted IPs” list to ensure that the new server will be able to
establish a connection to the Lotus Sametime server.
The TAS will open a connection to each of the community's Lotus Sametime
servers for its ongoing operations. The Lotus Sametime servers are used for
publishing users' telephony status and receiving notifications about the users'
Lotus Sametime status changes. By providing access to all the Lotus Sametime
servers in the community, you enable the TAS to load-balance its Lotus Sametime
requests among all available community servers. This is the recommended practice.
In some cases you may not want a particular Lotus Sametime server to be used by
the TAS; for example if the Lotus Sametime services a large community or "high
priority" group of people.
Note: If your deployment includes Lotus Sametime servers that reside in different
geographical locations, you may prefer to add a TAS to the trust list of the nearest
Lotus Sametime servers and prevent the TAS from attempting connections to the
Lotus Sametime servers that are located farther away.
About this task
Complete the tasks below according to whether you want each Telephony
Application Server to connect to a particular Lotus Sametime server:

Adding Telephony Application Servers to Lotus Sametime's list
of trusted servers
On each IBM Lotus Sametime Community Server, list the IP addresses of "trusted"
Telephony Application Servers from your Lotus Sametime Unified Telephony
deployment. A Community Server will accept connections only from trusted
servers. Each Community Server can trust a different set of servers, so you should
update each Community Server's trust list separately based on your deployment's
needs.
Before you begin
Print this table and fill it in for your deployment: for each Lotus Sametime
Community Server, list the IP addresses of all Telephony Application Servers that it
should trust.
IP addresses of trusted TAS servers

(separate with commas)
Lotus Sametime server (host name) Example: 192.0.2.0,
Example: stserver1.my_company.com 198.51.100.0
Procedure
Complete these steps for every LotusSametime Community Server in the

deployment, even if the servers are clustered:
1. Log in to the Integrated Solutions Console.
2. Click Sametime System Console > Sametime Servers > Sametime Community
Servers.
3. In the Sametime Community Servers list, click the deployment name of the
Lotus Sametime Community Server to be modified.
4. Click the Connectivity tab.
5. Under Trusted Servers, use the New IP Address field to enter the IP address of
all Telephony Application Servers that must connect to the Lotus Sametime
Community Server, and then click Add.
Separate multiple IP addresses with commas as shown in the table.
To delete an IP address from the list, select it and click Delete Selected.
6. Click OK.
7. Restart the Lotus Sametime Community Server for the change to take effect.
Excluding Lotus Sametime servers from a Telephony Application

Server
List the host names of IBM Lotus Sametime community servers that will be
"excluded" from connections to Telephony Application Servers. A TAS will not
attempt to connect to an excluded Lotus Sametime server.

Before you begin
Print this table and fill it in for your deployment: for each Telephony Application
Server, list the fully qualified host names of all Lotus Sametime community servers
that the TAS should exclude from communications:
Lotus Sametime servers to exclude (fully qualified

Telephony Application host names separated with semicolons)
Servers (host names) Example: stserver1.my_company.com;
Example: tas1 stserver2.my_company.com
About this task
A Telephony Application Server will not attempt to connect to an excluded Lotus

Sametime server. Each TAS can exclude a different set of Lotus Sametime servers,
so you should update each TAS exclusion list separately, depending on your
deployment's needs.
Procedure
1. Open the /enterprise/ibm/st.telephony.adapter.properties file for editing.
2. In the file, locate the servers.exclude.list key:
###############################
# Description - The list of servers which should not be connected
# Value - The list of server separated by ;
# Default value - null
###############################
#servers.exclude.list=TBD
3. Remove the comment marker (the # symbol), and remove the "TBD" (if
necessary); then type the list of fully qualified host names of the Lotus
Sametime servers that should be excluded from the current TAS.
For example:
servers.exclude.list=sales_st1.us.my_company.come;sales_st2.fr.my_company.com
5. Restart the Telephony Application Server.
Configuring the dial plan

This topic is an overview of the steps necessary to configure a dialing plan.

About this task
A dial plan contains groups and rules that govern how calls are routed.
The Global Numbering Plan is often used for interbusiness group call routing and
is separate from Business Groups.
Within a business group, there can be multiple numbering plans. A Business Group
is needed for every dial plan, along with one Numbering Plan. The numbering
plan can either be a common numbering plan or a private numbering plan. When
the Numbering Plan is created, a feature profile can be created for all SUT users
which is added to the Numbering Plan.
A Queue device (Multi-line hunt group) must be created as a place to store an

incoming call when an SUT user's preferred device is set to a computer. The call
remains on the MLHG until the user accepts the call on the soft-phone or deflects
it to another device. To create a Dial plan for SUT, the following steps must be
followed:
Example dial plan

This dial plan shows a single dial plan page, which consists of one business group,
one numbering plan, and handles three different endpoints and SUT subscribers.
Supported Number Formats table
The Supported Number Formats table can be used to represent the numbers
expected on SUT. It is not intended to be exhaustive, rather to highlight the most
interesting numbers, such as different formats for the SUT number, the softphone
number, and the desk phone numbers. Put the names of the Business Group and
Numbering plan above the Supported Number Formats table. Below the same
table are some of the key numbers for this system, such as the queue and
conference related numbers. The remaining tables have only a small subset of the
details needed, but gives an overview of components of the Dial Plan.

Creating office codes
Create office codes and directory numbers for IBM Lotus Sametime Unified
Telephony subscribers.
Procedure
1. Click Telephony Control Server > Global Translation and Routing > Directory
Numbers > Office Codes.
2. In the list of Office Codes, click the Add button.

3. In the "Add Office Code" section of the Add Office Code dialog box, fill in the
Country Code, Area Code, and Local Office Code field.

4. In the "Directory Number Range" section of the dialog box, enter beginning and
end values for the range of numbers in the Directory Number Start and
Directory Number End fields.
5. Click the button next to the Business Group field, select a business group from
the list, and click OK.

6. Click Save to save the new office code.
Creating Home DNs

Home Directory Numbers (Home DNs) are directory numbers that are available on
the Telephony Control Server platform in an IBM Lotus Sametime Unified
Telephony deployment. They must be created before subscribers can be allocated
onto the Telephony Control Server.
About this task
A Home DN is automatically created for each user during the import process;
during a typical deployment you would not need to create them manually. If you
find a need to create Home DNs yourself, follow the instructions in this topic.
Home DNs are used to indicate that the digit string is an SUT subscriber. It also
takes the appropriate SUT subscriber's office code which must exist already. The
dialed number is presented directly to the Home DN table. For each SUT
subscriber a Home DN must be configured with the fully qualified number. Home
DNs are created by first creating an office code and then creating a range of
extension numbers within that office code. The extension numbers here might be
scattered inside a range. Create the Home DNs starting from 1000 and ending at
1999. The combination of both results in the fully qualified number which is
known as a Home Directory Number (Home DN). There are two ways to choose
Home DNs:
v Define existing numbers as fully qualified directory numbers in TCS
v Create a set of numbers

Add the full public number (International format E.164 number) to the Home DNs
list. It is typical to apply scattered numbers to the TCS. For example, the range of
numbers is from 4000 to 4999 (1000 numbers). But the first five SUT numbers in
the range are:
v 4003
v 4011
v 4043
v 4045
v 4051
In this case, number 4004 is not a Sametime Unified Telephony number even
though it is inside of the 4000 range targeted. Each Home DN must be created
individually. Later, when configuring the destination codes, determine if it is a
Home DN and route it accordingly.
Procedure
1. In the CMP, go to Telephony Control Server > Global Translation and
Routing > Directory Numbers > Office Codes.
2. In the Office Codes list, click the Add button.

3. In the Add Office Code dialog box, enter the Country Code, Area Code, and
Local Office Code, and then click Save.

4. Return to the navigation tree and click Directory Numbers > Home Directory
Numbers.
5. Click Add button.

6. In the dialog box, select your Office Code, enter the extension number range
start and end values in the Directory Number Start and Directory Number
End fields, and select a Business Group Name; then click Save.

Results
When the Home DN numbers are created, they are displayed with a Vacant
destination type. Later, when SUT subscribers are created and assigned a number
from the list, the Home DNs change to End point, or in the case of the queue
number it changes to Service.
Different numbering plans available

A Numbering Plan specifies the format and structure of the numbers used within
that plan. It typically consists of decimal digits segmented into groups in order to
identify specific elements used for Identification, Routing, and Charging
capabilities
Private Numbering Plans are used for all special and Business Groups specific
dialing such as Service (features) Access Codes, Prefix Access Codes and Location
Dialing for Local, National, International and Extension Dialing.
A numbering plan is also used within a private numbering plan to identify the
locations, stations, and services:
v 9 or 0 = PNAC (Public/Private Network Access Code)

v 91 or 00 = National Access Code
v 9011 or 000 = International Access Code
v 5 = Extension dialing
The numbering plan is used by the translation engine of the TCS to interpret
dialed digits and find an appropriate destination for a call. Dialed digits are
always interpreted in the context of the calling subscriber or originating endpoint.
v For an outgoing call from the TCS, the dialed digits are interpreted by the
numbering plan attributed to the subscriber that is calls or deflecting the call to
one of its associated devices or a dialed digit string.
v For an incoming call to a subscriber, the dialed digits are interpreted by the
numbering plan attributed to the gateway or SIP softswitch that sent the
incoming call to the TCS, where the end point is defined.
The TCS supports four layers of numbering plans.
Default
The system provisioned a default during Business Group creation. The creation of
a business group includes the automatic creation of a default numbering plan. If
you need only one numbering plan in your business group, you have to do
nothing. If you want to use several numbering plans, you can define additional
numbering plans and one numbering plan can be set as a default numbering plan.
The default numbering plan cannot be deleted.
Private numbering plan
The private numbering plan is typically assigned to SUT subscribers, SIP gateways,
and softswitches. In the private numbering plan, local translation rules are stored.
All PNPs created by the administrator are called user defined. This PNP can be
deleted if there is no dependency on components of that NP edited to be the
default type. In this case the default becomes a user defined) or can be set as a
Common Numbering Plan. The PNP is a logical entity of subscribers/endpoints,
and the Dialing plan that govern their dialing pattern. The PNP exists in a private
network used by the private network subscribers belonging to a Business Group.
The Number Plan ID and Number Plan Name define all the related dialing objects
and tables. The valid ID range is “2 - 5999”. The default PNP ID = 1 (not used). A
PNP cannot be shared among different Business Groups. The system supports up
to 5999 PNPs.
Common numbering plan (CNP)
One numbering plan per business group can be assigned as a Common numbering
plan. As the name suggests, translation rules common to the business group or
company are stored here. It is an optional, user-defined PNP which is assigned the
type “Common.” Its purpose is to reduce data entries and use the data tables in
many PNPs efficiently in one BG. All PNPs of a BG can access the CNP data table
of the same BG only. They cannot access the CNP of any other BG. The CNP can
access the Global NP the same way any other PNP can.
Global numbering plan
The public E.164 numbering plan has special status. It forms a global level and
holds the translation rules that allow business groups to communicate with each
other. This is the default system numbering plan. The components of the global

numbering plan are common for the entire TCS and are accessible from all
business groups and numbering plans. Any data table that needs to be accessed
from all BGs/PNPs must be placed in the GNP. For example, every subscriber in
the system needs a home directory number. By placing the home DN tables in the
global numbering plan, all users that belong to any BG or PNP in the private data
tables can obtain directory number from these tables. When the TCS interprets the
dialed number, the numbers are found in the global data area if it is a local
subscriber. Display Number Modification tables, used to manipulate the displayed
and logged calling number on the called subscriber to a format that can be dialed,
are also common for all the system users and are defined in this plan. The Media
Server Announcements are defined at this level also.
Configuring business groups

Create one business group for each company supported by a Telephony
Application Server in an IBM Lotus Sametime Unified Telephony deployment.
Before you begin
Be you have completed the task, “Creating office codes” on page 175.
About this task
When creating a business group, a default office code must be entered for that
business group. When configuring business groups, you create an office code, a
business group, and a numbering plan. Within the numbering plan, you create the
PAC table, destination codes, destinations, Multi-Line Hunt Group (MLHG), the
endpoint profile, and the endpoints.
Procedure
1. Log in to the Common Management Portal (CMP).
2. Open the web browser using the Telephony Application Server URL:
https://TAS IP/management/
3. Click Users & Resources > Resources > Telephony Control Server Resources
> Office Codes.
4. In the list of office codes, click the check box in front of an office code, and
then click the Edit button.
5. In the Edit Office Code dialog box, make sure that the Overlap, International,
and National fields contain a zero (0); then click Save.
International and outside line access display the digit that must be dialed to
reach a public exchange line for national or international dialing.

Directory Numbers > Home Directory Numbers and verify that the directory
numbers you created earlier (in “Creating Home DNs” on page 177) are
available in the directory numbers list.
7. Go to Telephony Control Server > Business Group > Business Group Lists >
Business Groups.
8. In the list of business groups, click the Add button.

9. On the General tab of the Add Business Group dialog box, type a unique
name for the Business Group field (for example, BG1), type a
Display Number value, and then click Save.
The name of the business group must be unique; it cannot be changed after
you have saved it. The number plan is created automatically every time you
create a business group.

10. Back in the navigation tree, click Private Numbering Plans > Private
Numbering Plans.
The private numbering plan is automatically generated.

Creating numbering plans
The creation of a business group includes the automatic creation of one numbering
plan.
About this task
One numbering plan is created automatically when you create a business group. If
you want to use more than one numbering plans, you can define additional
numbering planes and set one numbering plan as a default numbering plan. You
can also create a common numbering plan if you have routing rules that are
common to all other numbering plans you have.
Procedure
1. To create a numbering plan, click TCS > Business Group > Available Business
Groups Then select your business group. Then click Private Numbering Plans
> Add.
2. In the CMP, go to Telephony Control Server > Business Group.
3. From the Available Business Groups, select the business group for which you
want to create the numbering plan.
4. Click Add to add your numbering plan for your business group.
5. On the next page, enter a name for the numbering plan.

6. Click Save.
7. If there are multiple numbering plans, set any one of them as Default by
clicking the drop-down arrow in the Status column. You can also set a specific
numbering plan as a Common Numbering plan (CNP) from the Status drop
down.

Creating default unified number feature profiles
Create a feature profile for a business group in an IBM Lotus Sametime Unified
Procedure
3. Enter user name (administrator@system.com) and password.
4. Click Telephony Control Server > Business Group.
5. Select the business group for which you want to create a feature profile. Then
click BG Options, and then Feature Profiles. Click Add.
6. From the General tab, check Default. Click Save.
7. From the Add Feature Profile page, change all the following services required
for a Sametime Unified Telephony subscriber to Yes:
a. Called Name Delivery
b. Called Number Delivery
c. Caller ID
d. Calling Name Permanent Presentation Status
e. Calling Number Permanent Presentation Status
f. CSTA, type 1
g. Call Transfer
h. Music on Hold
i. One Number Service (ONS), InboundAndOutbound
Note: If you set Call Forwarding Dependable then you can see and change
Subscribers' Call Forwarding Dependable numbers (otherwise Call Forward
Dependable works but you cannnot see the details).
8. Click Save. The feature profile is generated.
Creating a queue device

You can create a queue device by using the TAS graphical user interface.
About this task
Create a queue device to be used in a .csv file in later provisioning steps. Use the
following topics to configure the queue device.
Creating the queue number in users and resources

A Queue number is created using TAS graphical user interface.
Procedure
1. In the CMP, click Users & Resources > Users.
2. Select a user (administrator is fine for a newly installed system) or create a new
one.

3. Go to the Resources tab, click Add/Edit under the System Devices section.
4. On the next page, add a description and a phone number in GNF format for
the queue device. Then click Add. The queue device is created. There is no
need to assign the newly created device to the user.

Results
The queue device is now available to be used in a .csv file for user provisioning.
Creating the queue subscriber entry

This topic shows how to create a queue subscriber entry.
Before you begin
The CSTA service must be activated. The unified number service might not be
activated for the queue device. The default feature profile cannot be used for this
profile-only subscriber. Creating a queue subscriber is just like other subscribers,
but must be marked as profile only.

About this task
The number you use does not necessarily need to be a public number. However, it
must be dialable from any SUT subscriber. Otherwise, you must create a queue
number for each numbering plan. A queue subscriber entry must be created using
the TCS assistant screens with the following steps:
Procedure
1. In the CMP, go to Telephony Control Server > Business Group.
2. From the available business groups, select the business group for which you
want to create the queue subscriber entry.
3. From Available Private Numbering Plans, select your numbering plan.
4. Then click Members > Subscribers > Add to add your queue subscriber entry.

5. On the next page, enter the Office Code and Extension. For example, for queue
number +353 1 815 9999, see the screen capture.

6. Enter the display names appropriately for the queue.
Creating a multi-line hunt group

This section describes how to create a multi-line hunt group.
Before you begin
Create a queue subscriber.
About this task
This group is used for finding the next free line in a group. It is also used for
finding a free media server line for playing announcements and tones. The ring
tone is played from the media server. It might be replaced with other treatments
like customer announcements.
Procedure
1. In the CMP, click Telephony Control Server > Business Group.
2. Select the business group for which you want to create the multi-line hunt
group.
3. Click Teams > Hunt Groups. Click Add.

4. From the General tab, add the General Parameters. Some of the parameters
appear as the default values.
5. Enter the Subscriber ID, for example, +353 1 815 9999. The SUT subscriber
directory number created for the queue is provided as the Subscriber ID.

6. Click the ellipses next to the Intercept Announcements.
7. Select the ASK_ME intercept announcements. Click Ok.

8. Set the Hunt Type to Manual.
9. Set the Status as NotBusy.
10. Click Save. The hunt group is created but has no members.
Creating call routing components

Create call-routing components such as the dial plan, prefix access codes,
endpoints, destinations, and routes, in an IBM Lotus Sametime Unified Telephony
deployment.
The dial plan is the definition of a set of rules within a numbering plan to route
calls according to user requirements. This dial plan has only one business group
and only one private numbering plan (PNP). There are a series of digit patterns
that need to be supported and routed. The digit patterns are one of the following:
v A Sametime Unified Telephony number — any number that matches the pattern
of a Sametime Unified Telephony user matches a list of defined numbers. Once
it matches the call is routed.
v An external number — this number could be a public number, or a private
number supported on some other PBX. Sametime Unified Telephony has at least
one endpoint which points to a PBX or a SIP Gateway. When there is only one
endpoint pointing to a PBX then the routing becomes simple. If it is not a
number pattern supported directly by Sametime Unified Telephony, then it
routes to that PBX.

v An internally supported number — There are a few internally supported
numbers not covered by the Sametime Unified Telephony number set. These are:
– Softphone numbers — Sametime Unified Telephony numbers to which a
softphone prefix has been added to make it private.
– Queue Number — Every Sametime Unified Telephony system has a queue
number which typically falls into the range of SUT numbers and take the
same form.
– Conference Bridge and Local Park Slot numbers — these numbers are
handled by the Telephony Control Server and routed directly to the Media
Server Conferencing.
The dial plan
The dial plan configuration is a series of rules made up from:

v Prefix Access Codes
v Destination Codes
v Destinations
v Routes
v Endpoints
The work flow of a number going through a single numbering plan system can be
handled several ways. Commonly, a call is routed to an endpoint — a customer
PBX, WebSphere Application Server SIP Proxy or the Media Server Conference
endpoint. A call is also commonly routed to an SUT Subscriber. There are stages a
number must pass through to reach a subscriber. Here is the basic flow:
A number starts off in the Prefix Access Code. Assuming that a match was found
and translation or tagging (setting the nature of address, for example) is applied, it
can be moved to another numbering plan. Typically, and in this example, it is
moved to the Destination Code. From the Destination Code, a match must be
found. That destination is typically only one of two kinds of destinations, a

subscriber (noted as a Home DN) or a destination. If it is routed toward an SUT
Subscriber (Home DN), then there is no more needed from the Dial plan. If it is
routed to a destination, then that destination points it to an endpoint. A number
points to an endpoint through a route.
Prefix Access Codes (PACs)
The PAC table is where a number always starts its journey. If a number comes in
to a numbering plan, it must match a value in the PAC table or it is rejected. The
PAC table can be seen as a Number Normalization stage. Depending on the dial
plan design, it is desirable to normalize all numbers into the one format. A number
can arrive in one of many formats such as (but not limited to):
v International format
v National format
v Local format
v Private extension
v Extension prefixed with a department or steering code
The PAC entries are where these numbers can be translated and tagged. The PAC
table is where you can match specific patterns of numbers, add, or remove digits
from the number, tag it as being national or international number.
Destination codes
Destination codes are the server decides where the numbers go. It is where the
decision is made to send it to a subscriber, for example a Home DN, or to one of
many potential destinations, such as the IBM WebSphere Application Server SIP
Proxy, Conference Bridge, or the Customer PBX, or a PBX.
Destinations
A destination is the end of the line for a call. When a call gets to Destination, there
are no more decisions to make. For every endpoint, there must be a Destination.
However, this is not strictly always the case, especially with multiple numbering
plans.
Routes
Routes are the mechanism by which destinations are pointed to endpoints. Routes
can point to any endpoint in a system no matter what Numbering plan it is in. In
Lotus Sametime Unified Telephony, there is one route from a destination to an
endpoint. Many destinations can have a route pointing to the same endpoint. In
one example, there are two drastically different conference bridge numbers. They
each have a destination defined for them. But both of these destinations must point
to the one endpoint.
Endpoint
An endpoint is a device that connects one or more end-users to a video conference.

The endpoint may be on a single user's desktop or in a conference room shared by
a group of people.
Creating endpoints
Create one or more endpoints in an IBM Lotus Sametime Unified Telephony
deployment.

Creating an endpoint profile:
In an IBM Lotus Sametime Unified Telephony deployment, endpoints can connect

to a PBX, an IBM WebSphere Application Server SIP Proxy server, or an IBM Lotus
Sametime Media Server.
Procedure
2. Select the relevant Business Group from the Available Business Groups
dropdown menu.
3. Click Profiles > Endpoint Profiles > Add.
4. In the Add Endpoint Profile dialog box, type a descriptive name in the Name
field, and then click Save.

Creating an endpoint:
In an IBM Lotus Sametime Unified Telephony deployment, create a conferencing

endpoint that can connect to a PBX, an IBM WebSphere Application Server SIP
Proxy, or an IBM Lotus Sametime Media Server.
Procedure
2. Select the relevant Business Group from the Available Business Groups list.
3. Click Members > Endpoints > Add.
Setting up an endpoint for a PSTN gateway or PABX gateway:
Define an endpoint to connect to a customers PBX or gateway. An endpoint is

required for the PBX in order to support calls out to the PSTN in an IBM Lotus

Before you begin
The following pieces of information are required:

v Signaling IP address
v Port number
v Is authentication used?
v What protocol is used?
About this task
This information can be found by contacting your PBX administrator. Enter the
signaling IP address, port number, authentication and protocol used under the SIP
tab of the endpoint definition.
Setting up an endpoint for WebSphere Application Server SIP proxy server:
Create an IBM WebSphere Application Server SIP proxy server endpoint that
defines the WebSphere Application Server SIP Proxy, which is used for softphone
calls in an IBM Lotus Sametime Unified Telephony deployment.
Before you begin
An endpoint is required for the WebSphere Application Server SIP Proxy in order
to support softphone calling. The following pieces of information are required:
v WebSphere Application Server SIP Proxy IP address
v WebSphere Application Server SIP Proxy port number
v Transport protocol used
Procedure
1. Now, create the endpoint for the WebSphere Application Server SIP Proxy. In
the General tab, provide a value for the name attribute. Select the Registered
check box. Select the “...” button beside the Profile attribute field. In the dialog
that opens, select the newly created endpoint profile.
2. Select OK. The General tab looks like the following screen capture:

3. Now select the SIP tab.
a. Populate the IP address or FQDN field with the SIP Proxy IP address.
b. In the Port field, provide the SIP Proxy port number, for example, 5060.
c. In the Transport Protocol dropdown menu, select UDP.
d. In the Security section of the SIP tab, select the Add button.
e. In the SIP Configuration popup dialog, select the Trusted entity check box.
f. Select Ok. The SIP tab looks like the following screen capture:

4. Select the Alias tab. Select the Add button to provide an alias In the Name
attribute of the popup dialog. Use the SIP proxy IP address as the alias.
Select Ok to save the alias.
Note: An alias MUST be created for each endpoint, and each alias must be
unique. If the Media Server and WebSphere Application Server reside on the
same IP address, a unique alias must still be created for each. In this case,
name the alias the IP address followed by the port number. For example,
192.x.x.x_5060 for WebSphere Application Server, 192.x.x.x_5070 for Media
Server.
5. Click Ok to save the alias. Click Save to save the WebSphere Application
Server SIP Proxy endpoint. A dialog appears stating that the endpoint was
created successfully.
Setting up an endpoint for Cisco call manager:

For A-side calls to PSTN to set up a complete media path with Cisco Call Manager,
the following changes must be made to the Telephony Control Server using the
CLI (command-line interface) in an IBM Lotus Sametime Unified Telephony
deployment.
About this task
This task shows how to set the RTP Parameter Srx/Sip/ZeroIpOnHold to 0 and set
the CCM endpoint attribute Pre-Condition Signaling to 1.
Procedure
1. Open the command-line interface and log in as sysad.
2. At the Main Menu, select 1.
5. At the Modify Parameter prompt, enter Srx/Sip/ZeroIpOnHold.
6. At the line value max length <2047>:, enter 0 and then confirm your choice.
7. For the CCM endpoint, start at the Main Menu again, then select 6.
8. At the Application-level Management menu, select 5.
9. At the Zone Management (methods) menu, select 2.
10. Press the Enter key until the lineChange SIP endpoint attributes as bitmap
sums? (default: true): appears, and then enterfalse.
11. Press the Enter key until the line Pre-condition Signaling appears, and then
enter 1.
Example
Here's an example command-line interface session. User inputs are shown as

highlighted text.
Login to startCLI:
adsa107n1:~ # su - srx
srx on adsa107n1 using /dev/pts/0 ...
adsa107n1:/unisphere/srx3000/srx (376> startCli
Login: sysad
Main Menu:
Configuration Management.........................1
Fault Management......................................2
Performance Management..........................3
Security Management..................................4
System Management...................................5
Application-level Management.....................6
Open Logfile...............................................94
Show Callback Output................................95
Wait for Callbacks......................................96
Change Password......................................97
Expert Mode...............................................98
Exit.............................................................99
Selection: 1
Configuration Parameters............................1
Logging........................................................2
Return........................................................99

Selection: 1
browseParameterNames............................1
getParameterInfo........................................2
modifyParameter........................................3
createParameter.........................................4
deleteParameter.........................................5
loadConfigVersion......................................6
removeConfigVersion.................................7
getAllSavedConfigVersions........................8
saveCurrentConfigVersion.........................9
Return......................................................99
Selection: 3
modifyParameter:
name : Srx/Sip/ZeroIpOnHold
invariant settings:
name : Srx/Sip/ZeroIpOnHold
type : PARM_INT
lastUpdateMillis : 10.Sep.2009 11:37:28h (000 msec)
changeId : 0
descriptionString:
modifying variable parameters:

current value: 1
value <max length: 2047>: 0
executing method modifyParameter...
Ok.

(Hit enter on all other lines until change is saved)
Here is the example session that shows how to set the CCM endpoint attribute
PreCondition Signaling to 1
Main Menu:
Configuration Management...........................1
Fault Management........................................2
Performance Management...........................3
Security Management...................................4
System Management....................................5
Application-level Management......................6
Open Logfile................................................94
Show Callback Output.................................95
Wait for Callbacks.......................................96
Change Password.......................................97
Expert Mode................................................98
Exit..............................................................99
Selection: 6
Application-level Management:
Softswitch Management.....................................1
Signaling Management......................................2
Media Gateway Management............................3

Rate Area and Class of Service.........................4
Zone Management.............................................5
Translation/Routing Management......................6
Feature Management.........................................7
Network Element Security Management............8
Network Traffic Management.............................9
PCL Management...........................................11
Return.............................................................99
Selection: 5
Zone Management (methods):
Create Endpoint...............................................1
Modify Endpoint...............................................2
Remove Endpoint............................................3
Display Endpoint..............................................4
Create Alias.....................................................5
Remove Alias..................................................6
Display Alias....................................................7
Create Zone (Gatekeeper)..............................8
Modify Zone....................................................9
Remove Zone...............................................10
Display Zone.................................................11
Display Endpoint Profile................................12
Static SIP endpoint FQDNs Lookup..............13
Display SIP Endpoint Contact.......................14
Display SIP Endpoint Statistics.....................15
Return...........................................................99
Selection: 2
Endpoint Name <15 chars> (default: ): EP_MY_CUCM

Registration type <STATIC=1|DYNAMIC=2|UNCHANGED=-1 (min: -1 max: 2)>
(default: -1):
Registration Status <NOT_REGISTER=1|REGISTER=2|UNCHANGED=-1 (min: -1 max:
2)>(default: -1):
Transport Protol <UNDEFINED=0|UDP=1|TCP=2|TLS=4|UNCHANGED=-1 (min: -1 max: 4)>
(default: -1):
Signaling Primary IPAddress <xxx.xxx.xxx.xxx|FQDN format|DomainName|_ for
unchanged> (default: _):
Signaling Primary Port <range 0-65535, any unused port> (default: -1):
Signaling Secondary IPAddress <xxx.xxx.xxx.xxx|0.0.0.0 for empty IP
address|FQDN format|_for unchanged> (default: _):
Signaling Secondary Port <range 0-65535, any unused port> (default: -1):
Max number of SIP Sessons <Max number sessions allowed per subscriber
(min: -1 max: 10000)> (default: -1):
Max number of SIP Originating Sessions <Max number sessions allowed per
Endpoint (min: -1 max: 5000)> (default: -1):
Max number of SIP Terminating Sessions <Max number sessions allowed per
Endpoint (min: -1 max: 5000)> (default: -1):
Network Server Failover Support (Yes/No) <NO=0|YES=1|UNCHANGED=-1
(min: -1 max: 1)> (default: -1):
Change SIP endpoint attributes as bitmap sums? (default: true): false
Change SIP endpoint attributes one by one? (default: true):
Originating Tenant Group required <0=false|1=true|-1=unchanged> (default: -1):
Calling Party Category required <0=false|1=true|-1=unchanged> (default: -1):
Send OLI as SIP-OLI <0=false|1=true|-1=unchanged> (default: -1):
Send OLI as ISUP-OLI <0=false|1=true|-1=unchanged> (default: -1):
Ignore Ingress CPC OLI <0=false|1=true|-1=unchanged> (default: -1):
Ignore Incoming OTG <0=false|1=true|-1=unchanged> (default: -1):
UPDATE conf dialogs supported <0=false|1=true|-1=unchanged> (default: -1):
Send resp during session updates <0=false|1=true|-1=unchanged> (default: -1):
SIPQ Signaling supported <0=false|1=true|-1=unchanged> (default: -1):
3GPP IMS Endpoint <0=false|1=true|-1=unchanged> (default: -1):
Pre-condition Signaling <0=false|1=true|-1=unchanged> (default: -1):
1

Creating a prefix access code
This section describes how to create a prefix access code table to handle the
various numbers the system manages including the softphone with its prefix.
Procedure
4. Go to Telephony Control Server > Business Group.
5. Select the business group for which you want to create the Prefix Access Codes
(PAC) table. Select the Available Private Numbering Plan. Select Prefix Access
Codes. Click Add.
6. From the General tab, enter the prefix code parameters for the business group.
Refer to your numbering plan.
7. The following parameters are an example only:
a. Prefix Access code: 0
b. Minimum Length: 3
c. Maximum Length: 24
d. Digit Position: 1
e. Digits to Insert: 4989
f. Prefix Type: Off-net Access
g. Nature of Address: International
h. Destination Type: None
8. Click Save.
9. Continue to add access codes from your numbering plan table. As you Save
each addition, the access codes are listed in the Prefix Access Code menu.
Creating a destination code table

This section describes how to create a destination code table. This table is used to
perform an analysis on the normalized international number, for example, without
traffic discrimination digits.
Procedure
4. Go to Telephony Control Server > Business Group.
5. Select the business group for which you want to create the Destination table.
Select the Available Private Numbering Plan > Translation > Destination
Codes. Click Add.
6. From the General tab, enter a PAC table name or click the ellipsis next to
Destination Code: and choose it from a list. Click OK.
7. The following parameters are an example only:
a. Destination Code: 498961506
b. Nature of Address: International
c. Routing Area: RA_TAS1
d. Destination Type: Home DN

e. Office Code: +49 (89) 6150
8. Click Save. Create another destination code using the Destination Code:
498961506. Click Save.
9. From the General tab, add the Sametime Unified Telephony prefix. Click Save
a. Destination Code: 6981
b. Nature of Address: International
c. Routing Area: RA_TAS1
d. Destination Type: Destination
e. Destination Name: DEST_TAS1
10. Click Save.
Creating destinations
A destination is used to define an off-network trunk. Routes are created within the
destination to handle the signaling traffic for this destination.
About this task
Be sure to create the destination within the correct numbering plan. To create a
destination, follow these steps:
Procedure
1. Click Telephony Control Server > Business Group . Select the relevant
Business Group from the Available Business Groups dropdown menu. Select
the relevant Numbering Plan from Available Private Numbering Plan
dropdown menu.
2. Click Destinations and Routes > Destination > Add.
3. In the destination dialog, provide a value for the Name attribute.
4. Select Save.
5. A dialog appears stating the destination was successfully created.

Creating a route
A route is used to provide a link from a destination to an endpoint. Routes are
created by editing the destination that was created in the previous topic.
Before you begin
Make sure that a Destination has been created. Also, ensure that an endpoint has
been created. See the previous topic for information.
Procedure
a. Select the relevant Business Group from the Available Business Groups
dropdown menu.
b. Select the relevant Numbering Plan from the Available Private Numbering
Plan dropdown menu.
2. Click Destinations and Routes > Destinations. Select the recently created
destination In the destination dialog. Then select the Routes tab, then click
Add.
3. In the Routes tab, values must be provided for the following attributes. Provide
a numeric value for the ID attribute. ID numbers must be used in ascending
order, with the highest priority route receiving the lowest ID number Select the
“...” button beside the 'SIP Endpoint' attribute field. On the dialog that opens,
select the relevant numbering plan, in this instance, NP_BG_TAS02.

4. Select Ok. Selecting Ok opens a separate dialog containing a list of endpoints
relevant to the numbering plan.
5. Select Ok. The Route dialog looks like this:

6. Select Save.
7. If more that one route has been assigned to a TAS node, for example, more
than one Media Server configured for TAS, the route list must be prioritized.
Adding subscribers for testing

A subscriber must be created before you create the multi-line hunt group (MLHG).
Procedure
1. Log in to the Common Management Portal (CMP):

a. Open a browser and navigate to the Telephony Application Server:
https://TAS_IP/management/
b. Log in using the administrator user name (administrator@system.com) and
password.
3. Select the business group for which you want to create the destination table.
4. Click Available Private Numbering Plan to Members > Subscribers.
5. Add a subscriber:
a. Click Add.
b. On the General tab, add the general parameters.
c. Click Save.
d. From the Advanced tab, add the advanced parameters.
e. On the Services tab, verify that the unified number is set to No.
f. Click Save.
6. Repeat step 5 to create two more subscribers, this time with SIP phones and no
profiles, and using different extensions.
Conducting simple call tests

To verify that telephone calls can be made using Sametime Unified Telephony,
execute the tests in the table with users from only one TAS and with users from
multiple TAS.
About this task
In the table, tests can be read as follows:

v A -> B means one test: “A” calls “B”
v A <-> B means two tests: “A” calls “B” and “B” calls “A” where A and B are
Sametime Computer Phone, Sametime Mobile Phone, Desk Phone, and so on
For example, 1. “Sametime Computer Phone -> Sametime Desk Phone” means “a
telephone call from Sametime client where Sametime Computer Phone is selected
as preferred device to Sametime client where a desk phone number is selected as
preferred device. 2. “Sametime Computer Phone -> Mobile Phone” means a
telephone call from Sametime client where Sametime Computer Phone is selected
as preferred device to a mobile phone number.
Test Within same TAS Cross TAS

Sametime Computer Phone X X
-> Sametime Computer
Phone
Sametime Desk Phone -> X X
Sametime Desk Phone
Sametime Mobile Phone -> X X
Sametime Mobile Phone
<-> Sametime Desk Phone
<-> Sametime Mobile Phone
Sametime Desk phone <-> X X
Sametime Mobile Phone

Sametime Computer Phone X
-> Desk Phone
-> Mobile Phone
-> Queue Number
Desk Phone -> Queue X
Number
Mobile Phone -> Queue X
Number
Configuring conferencing
Configure IBM Lotus Sametime Unified Telephony to support user phone
conferences.
Before you begin
Make sure both basic computer calls and desk phones work correctly. If basic calls
work, then the intercepts also work.
About this task
Conferencing terminology
Conferencing is the act of including 3 or more people in one telephone

conversation. "Ad hoc" conferencing is where this conference is not typically
pre-arranged; it can happen on the spur of the moment. There are 3 different
methods to create an ad hoc conference:
v A unified telephony user selects 2 or more other contacts (the contacts do not
also have to be using Lotus Sametime Unified Telephony) and then selects the
option to call them, and all 3 users are called into the conference. This is known
as "Click to Conference".
v A unified telephony user is on a phone call with one person, and decides to
include an additional contact in the current call. A conference is created where
the original two participants are automatically transferred into the conference,
and the third contact is then called into the conference. This is known as a "Drag
and Drop Conference" as it typically occurs when an additional user is dragged
into an already existing two-way phone call.
v A unified telephony user is on a phone call, when a second call occurs. The
unified telephony user pauses the first call to talk to the second party, and then
decides to join both calls to make one call. A conference is created where all
three contacts can freely converse. This is known as "Call Merging".
Before you set up conferencing capabilities, you must establish two conferencing
numbers, which will be covered in topics which follow.
v Conference Bridge Number — a publicly accessible number, used for Click to
Conference calls
v Local Park Slot Number — a private number, used for drag and drop
conferencing
Then, there are five actions that must be taken to enable these conferencing calls:

Enabling conferencing on the Media Server
Use these topic to establish a connection with the Media server and then with
numbers assigned to the media server conferencing feature.
Creating Media Server connection

The Media Server must be connected to the Telephony Control Server to complete
the configuration.
Procedure
1. To create a connection to the Media Server for Conferencing, go to: Operation
& Maintenance > Configuration & Monitoring > Telephony Control Server
Configuration > Media Server Connections > Add.
2. In the following screen, select TAS Node – Small Deployment. Click Add to
add the connection.

3. Enter a Connection Name for this conferencing connection. Set the BCom
Provider to MSProv1.
4. The new connection name appears under Cluster Connections. Click Save to
finish.

Binding the conferencing numbers
Using the entry in the Media Server's list of nodes created in the last section,
configure the Media Server Conferencing details.
Procedure
1. Open the node window by clicking the entry in List of Nodes.
2. Go to the Address Binding tab. Set the conference number and the Local Park
Slot number. Click the number for the terminal. A window opens where the
correct, fully qualified GNF number, which includes +, can be set.

3. Click Save after the number is set. The updated number appears in the
Expressions column of the Address Bindings table. Repeat this step for both
the Conference Bridge and local park slot number.
4. Click Save. The node administration page appears. Click the Providers tab and
select the IP Telephony (SIP) link.
5. Configure the settings that the Media Server Conferencing feature requires to
send SIP invites to TCS. Set Hostname/IP address to the SIP Signaling manager
IP of TCS: sipsm1_vip in the node.cfg file. Set the Port number to 5060. Set the
Transport Protocol to User Datagram Protocol (UDP). Click Save.

Note: The addresses in the lower pane of this window, show the IP addresses
and ports on which the Media Server is listening. The Media Server is
configured to operate on a non-standard port 5070 and for secure transport
5071. When creating a SIP end point in TCS to the Media Server conference
bridge, these non-standard ports must be used.
Updating the dial plan

Use these topics to configure the dial plan to handle calls coming from the Media
Server.
About this task
The numbering plan, where the media server conferencing end point is defined,
must support the dialing of any numbers supported on the system. The conference
bridge may need to dial all kinds of numbers, both public and private. Dial
restrictions must also be carefully considered. If the dial plan consists of multiple
numbering plans it must be configured to support conferencing numbers from all
numbering plans.
Creating conferencing endpoint

A trusted, statically registered SIP endpoint must be provisioned for each Media
Server to allow receiving and sending SIP calls from or to the SIP interface of the
Media Server.
About this task
This SIP endpoint must be provisioned for the correct transport type and the
domain name or IP address which it uses as a contact in outbound requests to the
TCS must be added as an alias. The Media Server endpoint used for SIP
conferencing is normally created in the common numbering plan (CNP) of the
business group. Use only fully qualified numbers, for example, GNF numbers for
public E.164 numbers and fully qualified private numbers for private network
numbers. There are two basic steps covered in this section:
v Creating the endpoint profile required for any end point
v Creating the end point
Procedure
1. Go to Telephony Control Server > Business Group. Choose the suitable
business group. Then click Numbering Plan. Choose the suitable numbering
plan. Then go to Endpoint Management > Endpoint Profiles > Add.
2. To create the endpoint profile, from the CMP, first create an endpoint profile
named EPP_CONF_IRL. Select the Routing Area created in the Configuring
Announcements from a list by clicking the ellipsis.

3. Select the Routing Area from the list and click Ok.
4. Click Save to save the profile.

5. Then, create an SIP endpoint with the specifics of the Media Server. Go to
Telephony Control Server > Business Group. Choose the suitable business
group. Then click Numbering Plan. Choose the suitable numbering plan.
Then go to Endpoint Management > Endpoints > Add

6. Name the endpoint. Check the check box marked registered and click the
ellipsis to choose the profile.
7. Choose the Endpoint Profile that was created.
8. Skip the Attributes tab. Click the SIP tab. Enter the IP address of the TAS.
Then enter the port for the Media Server SIP. The default is 5070. Encrypted
servers use 5071. In this single NIC configuration, the WebSphere Application
Server SIP Proxy and Media Server SIP connection use the same network
adapter. If the Transport Protocol is UDP or TCP, the default Signaling
Binding port value is 5070. If the Transport Protocol is TLS or MTLS, the
default Signaling Binding port value is 5071.

9. If digest authentication is activated in the system, the media server can be set
up to be a trusted endpoint. In the Security section, add an element. Check
the Trusted check box for the Media Server. Click the button next to All Ports
and click Ok.
10. After configuring the security section, click Save.

11. In the Alias tab, add an alias with the IP address of the Media Server. The
alias determines which incoming SIP invite belongs to what numbering plan
based on matching the From IP in the header of the SIP invite. Click Save.
Creating conferencing destinations and routes

This topic describes how to create a destination which points to an end point
through a route
Procedure
1. Go to Telephony Control Server > Business Group. Choose the suitable
business group. Then click Numbering Plan. Choose the suitable numbering
plan. Then go to Destinations and Routes > Destinations > Add.

2. Enter the name of the destination. Click Save.
3. To point the newly created destination to the conference bridge end point, open
the destination and go to the Route Tab. Click Add. The route tab only
becomes available when the destination has been saved. When initially creating
the destination, it needs to be saved and then opened again.

4. Give the Route and ID, ensure that Type is set to SIP Endpoint. Click the
ellipsis button to Choose an SIP End Point.
5. After choosing the numbering plan a list of endpoints is displayed. Select the
conferencing end point. Click Save.

6. Go to the Route List tab. Click the check box under Prioritized. Click Save.
Creating conference destination codes

This task shows you how to create a destination code that matches the conference
bridge number. It also shows you how to create another destination code which
matches the local park slot number and directs traffic to the conference bridge
destination.
About this task
Many destinations are matched with a range of numbers. Conferencing presents a

special challenge. Two destination codes must be created for the local park slot and
the conference bridge to ensure that conferencing works properly.
Procedure
1. Go to Telephony Control Server > Business Group. Then select a Business
Group.
2. Then go to Available Private Numbering Plan. Select a Numbering Plan. Then
go to Translation > Destination Codes > Add.

3. In the Destination Code field, enter the code. Set the Nature of Address field
to International and the Traffic Type to None.
4. Set the Destination Type to Destination and choose the name of the
destination in the Destination Name field.

5. Repeat steps 1 thorough 4 with the other code in the Destination code field.

6. The additional destination codes are shown in the list of destination codes.

Configuring conferencing resources on TAS
The TAS requires details on the media server conference bridge numbers. It needs
to be able to break down these numbers into their parts country code, area code
and local code.
Defining the conferencing resources on TAS

The TAS must be configured to recognize the numbers for the Media Servers
Conferencing feature.
About this task
Follow these steps to define the following features in the "Users & Resources"
section of CMP:
v SIP Domain
v Office code that the conference bridge and local park slot use
v Conference Codes
Procedure
1. To define the SIP Domain, go to User & Resources > Resources > Media
Server Resources > SIP Domains.
2. Click Add. The SipDomain ID can be any numeric value, as long as it is unique
within the system. There is typically only one SIP Domain. The Sip Domain is
the IP address which appears in the SIP headers from the Media Server. It must
be set to the IP address used by the Media Server Conference bridge. Click
Save.

3. Select the Office Codes section. Click Add.
4. Set the values in the following fields:

a. Set the Office Code ID to the combination of country code, area code, and
local code.
b. Set the Country Code, Area Code, and Local Office Code according to the
local values.
c. Set the Overlap to zero. The overlap is the number of digits that the
extension overlaps onto the local office code. If it is set to 1, the extension is
using one digit from the Local Office Code.
d. Set the Outside Line Access to the number that is dialed to reach the
outside line for national and international calls.
e. Click Save. The office code entry appears in the list.

5. Select Conference Devices.
Two conference devices must be added: one for the conference bridge number
and one for the local park slot number.
Note: A park slot is a phone number that is reserved for storing, or "parking"
calls that are put on hold. A dedicated park slot can be accessed by all other
phones in the system so that any user can pick up the call that is on hold.
6. Create a conference device for the conference bridge as follows:

a. Click Add.
b. Verify that the correct Sip-Domain ID is selected (if only one has been
define, it si selected by default).
c. If there are multiple office codes configured on this system, ensure that the
correct office code is selected.
d. Set the Extension field for the conference bridge.
e. Click OK to save this conference device definition.

7. Create a conference device for the local park slot in the same manner:
a. Click Add.
b. Verify that the correct Sip-Domain ID is selected (if only one has been
define, it si selected by default).
c. If there are multiple office codes configured on this system, ensure that the
correct office code is selected.
d. Set the Extension field for the local park slot (this will be different than the
extension used for the conference bridge).
e. Click OK to save this conference device definition.
8. Verify that both resources were correctly added and recognized on the system,
and that the number of assigned queue resources has increased by two. If it has
not, remove the resources from Users & Resources and create them again.

Setting the conference number
This topic describes how to verify that the conferencing number was set in the
response file during installation.
About this task
Although the conferencing number is set during the installation of the TAS, if it is
incorrect, it can be difficult to diagnose. Verify that the number is set correctly
before continuing the configuration by following these steps.
Procedure
1. In the Configuring and Monitoring section of the CMP, click the Root Cluster
on the left side of the screen. Click TAS Node — Small Deployment.
2. Find Conferencing Service by sorting the results by names. Click Conferencing
Service.

3. In the bridgeNumberToll field, ensure that the correct Conference Bridge
number is set.
4. Click Save to save and exit this window.
Modifying endpoint in CLI

Sending the User Format in Telephone Subscriber Format, Ignoring Incoming OTG
and Accepting the Billing Number are only administrable through the
command-line interface must be set on the Media Server Endpoint.
About this task
Send User Format in Telephone Subscriber Format must be set on the Media
Server Endpoint to force the TCS to send GNF numbers to it. It adds a + in front
of every international number sent to the Media Server. The administrator must
ensure that all numbers sent to the Media Server are in International format.
Ignore Incoming OTG must be set to force the TCS to ignore the Answer flag
setting on MLHG announcements for it. Accepting Billing Number must be set on
the Media Server Endpoint to force the TCS to use a 2-> n conference originator's
numbering plan and toll restriction services for the calls to the added parties.
Procedure
1. Start a secure remote shell to the TCS node using PuTTy. Or, log in to the TCS
node with the srx user account.

2. Issue the command startCli.
3. Log in as sysad.
4. At the Main Menu, enter 6 to select Application-level Management.
5. At Application-level Management, enter 5 to select Zone Management.
6. At Zone Management, enter 2 to select Modify Endpoint.
7. On the Endpoint Name line, enter the name of the conference end point.
8. Keep the defaults for the first 12 lines. At the line Change SIP endpoint
attributes as bitmap sums?, enter false.
9. Keep the defaults for the next six lines. At the line, Ignore Incoming OTG
<0=false|1=true|-1=unchanged> (default: -1):, enter 1.
10. Keep the defaults for the next 10 lines. At the line Send User Format in
Telephone Subscriber Format <0=false|1=true|-1=unchanged> (default: -1):,
enter 1.
11. Keep the defaults for the next 19 lines. At the line Accept billing number
<0=false|1=true|-1=unchanged> (default: -1):, enter 1.
12. Keep the defaults for the next 10 lines. At the prompt, Do you want to
execute this action? (default: yes):, enter yes.
13. Enter 99 to Return. At the Zone Management menu, enter 99 to Return.
14. At the Application-level Management menu, enter 99 to Return.
15. At the Main Menu, enter 99 to Exit.
Example
Start a secure remote shell to the TCS node (for example, using PuTTy) or log in to
the TCS node with the srx user account. In the following example, user input is
shown as highlighted text.

All Rights Reserved

NOTE: You may use this software only in accordance

with the terms of your license agreement, located on any of the installation
CDs for this product. (This process is running as "RtpAdmCli01")
Login: sysad
Main Menu:
Open Logfile............................94
Change Password.........................97
Expert Mode.............................98
Exit....................................99

Selection: 6
Softswitch Management..........................1
Signaling Management...........................2
Media Gateway Management.......................3
Rate Area and Class of Service.................4
Zone Management................................5
Translation/Routing Management.................6
Feature Management.............................7
Network Traffic Management.....................9
Service Broker Management.....................10
PCL Management................................11
Return..................................99
Selection: 5
Create Endpoint................................1
Modify Endpoint................................2
Remove Endpoint................................3
Display Endpoint...............................4
Create Alias...................................5
Remove Alias...................................6
Display Alias..................................7
Create Zone (Gatekeeper).......................8
Modify Zone....................................9
Remove Zone...................................10
Display Zone..................................11
Display Endpoint Profile......................12
Display SIP Endpoint Contact..................14
Display SIP Endpoint Statistics...............15
Return..................................99
Selection: 2
Endpoint Name <15 chars> (default: ):

<enter the name of your conference end point here>
Registration type <STATIC=1|DYNAMIC=2|UNCHANGED=-1

Registration Status <NOT_REGISTER=1|REGISTER=2|UNCHANGED=-1

Transport Protol <UNDEFINED=0|UDP=1|TCP=2|TLS=4|UNCHANGED=-1

Signaling Primary IPAddress

<xxx.xxx.xxx.xxx|FQDN format|DomainName|_ for unchanged> (default: _):
Signaling Primary Port <range 0-65535, any unused port> (default: -1):
Signaling Secondary IPAddress
<xxx.xxx.xxx.xxx|0.0.0.0 for empty IP address|FQDN format|_ for unchanged>
(default: _):
Signaling Secondary Port <range 0-65535, any unused port> (default: -1):
Max number of SIP Sessiunified number<Max number sessiunified numberallowed
per subscriber
(min: -1 max: 10000)> (default: -1):
Max number of SIP Originating Sessiunified number
<Max number sessiunified numberallowed per Endpoint (min: -1 max: 5000)>
(default: -1):
Max number of SIP Terminating Sessiunified number

<Max number sessiunified numberallowed per Endpoint (min: -1 max: 5000)>
(default: -1): Network Server Failover Support (Yes/No)
<NO=0|YES=1|UNCHANGED=-1 (min: -1 max: 1)> (default: -1):
Change SIP endpoint attributes as bitmap sums? (default: true):
false
Change SIP endpoint attributes one by one? (default: true):
Originating Tenant Group required <0=false|1=true|-1=unchanged> (default: -1):
Calling Party Category required <0=false|1=true|-1=unchanged> (default: -1):
Send OLI as SIP-OLI <0=false|1=true|-1=unchanged> (default: -1):
Send OLI as ISUP-OLI <0=false|1=true|-1=unchanged> (default: -1):
Ignore Ingress CPC OLI <0=false|1=true|-1=unchanged> (default: -1):
Ignore Incoming OTG <0=false|1=true|-1=unchanged> (default: -1): 1
UPDATE conf dialogs supported <0=false|1=true|-1=unchanged> (default: -1):
Send resp during session updates <0=false|1=true|-1=unchanged> (default: -1):
SIPQ Signaling supported <0=false|1=true|-1=unchanged> (default: -1)
3GPP IMS Endpoint <0=false|1=true|-1=unchanged> (default: -1):
Pre-condition Signaling <0=false|1=true|-1=unchanged> (default: -1):
Early-Session Media Signaling <0=false|1=true|-1=unchanged> (default: -1):
Survivable <0=false|1=true|-1=unchanged> (default: -1):
tel URI Support Required <0=false|1=true|-1=unchanged> (default: -1):
tel URI Support Allowed <0=false|1=true|-1=unchanged> (default: -1):
Send User Format as Received <0=false|1=true|-1=unchanged> (default: -1):
Send User Format in Telephone Subscriber Format <0=false|1=true|-1=unchanged>
(default: -1): 1
Send User Format as Local Number without phone-context
<0=false|1=true|-1=unchanged> (default: -1):
Send User Format as Local Number with phone-context
Treat All Numeric Userinfo as user=ip
SIP Signaling History <0=false|1=true|-1=unchanged> (default: -1):
SIPQ Truncate MIME <0=false|1=true|-1=unchanged> (default: -1):
Allow Prefixes <0=false|1=true|-1=unchanged> (default: -1):
P-DCS-Billing-Info Supported <0=false|1=true|-1=unchanged> (default: -1):
Generate Reason Header in response without Reason Header
Send Reason Header for Q.850 Protocol <0=false|1=true|-1=unchanged>
(default: -1):
Send Reason Header for SIP Protocol <0=false|1=true|-1=unchanged>
(default: -1):
Do not send Reason Header <0=false|1=true|-1=unchanged> (default: -1):
Do not send CIC Flag <0=false|1=true|-1=unchanged> (default: -1):
Media Redirection using 302 Moved Temporarily override
Attempt to reroute the endpoint with secondary IP address
endpoint server <0=false|1=true|-1=unchanged> (default: -1):
The endpoint needs to save AoR in each contact
Call Center Application Enabled <0=false|1=true|-1=unchanged>
(default: -1):
Using Domain Name <0=false|1=true|-1=unchanged> (default: -1):
Use Q.850 cause value from SIP Reason header or Reason Table
Accept billing number <0=false|1=true|-1=unchanged> (default: -1):
1
Allow sending of Insecure Referred-By header parameter to a transfer
target <0=false|1=true|-1=unchanged> (default: -1):
Send preferred identity header <0=false|1=true|-1=unchanged>
(default: -1):
Send domain name in from header <0=false|1=true|-1=unchanged>
(default: -1):
Send forwarding number in headers <0=false|1=true|-1=unchanged>
(default: -1):
Do not send diversion header <0=false|1=true|-1=unchanged>
(default: -1):
Do not send INVITE without SDP <0=false|1=true|-1=unchanged> (default: -1):

Country Code <0-3 chars> (default: _):
Default VTG NameDomain <0-100 chars, syntax: access=sip:TGName.TGDomain>
(default: _):
IP Security Profile: <To leave Unchanged enter /001 (max length: 63)>
(default: ):
Account Authorization and Services <AUTH_EP=3|NO_SVC=4|UNCHANGED=-1
Do you want to execute this action? (default: yes): yes
*** Modify Endpoint executed successfully ***

Ok.

Create Endpoint................................1
Modify Endpoint................................2
Remove Endpoint................................3
Display Endpoint...............................4
Create Alias...................................5
Remove Alias...................................6
Display Alias..................................7
Create Zone (Gatekeeper).......................8
Modify Zone....................................9
Remove Zone...................................10
Display Zone..................................11
Display Endpoint Profile......................12
Display SIP Endpoint Contact..................14
Display SIP Endpoint Statistics...............15
Return..................................99
Softswitch Management..........................1
Signaling Management...........................2
Media Gateway Management.......................3
Rate Area and Class of Service.................4
Zone Management................................5
Translation/Routing Management.................6
Feature Management.............................7
Network Traffic Management.....................9
Service Broker Management.....................10
PCL Management................................11
Return..................................99
Main Menu:
Open Logfile............................94
Change Password.........................97
Expert Mode.............................98
Exit....................................99
dubtcs02node1:/unisphere/srx3000/srx (101>

Testing conference features
Verify that the IBM Lotus Sametime Unified Telephony features have been
configured successfully by testing each set of features.
Before you begin
Print this topic so you can record test results and comments in the provided tables.
About this task
All tests must pass if Lotus Sametime Unified Telephony is properly configured. A
test passes when audio is heard in both directions by all participants in a
conference.
In the tables below, the term "Sametime preferred device" indicates that a user is
using the Lotus Sametime client to make or accept conference calls (in these test,
the Sametime preferred device is set to either "Computer" or "Desk phone"). When
the term "Sametime preferred device" is not used (for example, in a test using
"Mobile phone" as the device), the user is using an external device with a
non-Sametime Unified Telephony number.
Procedure
1. Test the Click-to-Conference feature. For each test, set each user's preferred
device as shown, and then have User 1 complete the following actions to
conference with User 2 and User 3:
v Select User 2 and User 3.
v Call selected users.
Table 1. Click-to-Conference test settings
Device Pass? Comments

Test 1 v User 1: Sametime
preferred device is
set to Computer
v User 2: Sametime
preferred device is
set to Computer
v User 3: Sametime
preferred device is
set to Computer
preferred device is
set to Desk phone
v User 2: Sametime
preferred device is
set to Desk phone
v User 3: Sametime
preferred device is
set to Desk phone

Device Pass? Comments
Test 3 v User 1: Mobile
phone
v User 2: Mobile
phone
v User 3: Mobile
phone
preferred device is
set to Computer
v User 2: Sametime
preferred device is
set to Desk phone
v User 3: Mobile
phone
preferred device
set to Computer
v User 2: Desk
Phone
v User 3: Mobile
Phone
2. Test the Drag-and-Drop Conference feature. For each test, set each user's
preferred device as shown, and then have User 1 complete the following
actions to conference with User 2 and User 3:
v Select User 2 and call.
v Click Actions > Invite Others
v Select User 3.
Table 2. Drag-and-Drop Conference test settings
Sametime preferred
device Pass? Comments
Test 1 v User 1: Computer
v User 2: Computer
v User 3: Computer
v User 2: Desk
phone
v User 3: Desk
phone
v User 2: Mobile
phone
v User 3: Mobile
phone

Sametime preferred
device Pass? Comments
v User 2: Computer
v User 3: Mobile
phone
v User 2: Computer
v User 3: Desk
phone
3. Test the conference call controls and audio streams. For each test, complete the
specified actions and note the results:
Actions Pass? Comments

Test 1 1. Dial a conference
number from
Lotus Sametime.
2. Dial the same
conference
number from
another device
(for example, a
mobile phone or a
desk phone).
Test 2 1. Verify the audio
stream when the
moderator mutes
one participant.
2. Verify the audio
stream when the
moderator
unmutes the same
participant.
stream when the
moderator mutes
all participants.
2. Verify the audio
stream when the
moderator
unmutes all
participants.
stream when a
participant mutes
himself.
2. Verify the audio
stream when the
same participant
unmutes himself.

Actions Pass? Comments
stream when the
moderator pauses
the conference.
2. Verify the audio
stream when the
moderator
resumes the
conference.
Test 6 1. Verify that the
moderator can
disconnect a
participant.
2. Verify that the
moderator can
re-invite the same
participant.
Test 7 Verify that a
participant can
transfer the call to
another device
during the conference
without disturbing
anyone else. For
example, make sure
that the transfer
occurs, and make
sure that hold music
is not played.
Configuring security
This section describes how to enable security using TLS encruption in an IBM
Enabling TLS encryption for the deployment

Enable TLS encryption for the servers in an IBM Lotus Sametime Unified
About this task
Enabling TLS encryption involves extracting the SSL certificate from the
deployment's SIP Proxy/Registrar, importing it to all Telephony Control Servers
and Telephony Application Servers, modifying security settings, and then restarting
all servers.
Extracting the SSL certificate used by the SIP Proxy server

Extract the SSL certificate from an IBM WebSphere SIP Proxy/Registrar server so it
can be imported to other servers in the deployment for enabling TLS encryption.
Procedure
1. On the SIP Proxy/Registrar server, log in to the Integrated Solutions Console as
the WebSphere administrator.

2. Click Security > SSL certificate and key management > Key stores and
certificates > NodeDefaultTrustStore > Signer certificates.
3. Select the certificate with the IP address of the SIP Proxy, and click the Extract
button.
A “.cer” file is created to contain the certificate.
4. Copy the certificate (the .cer file) so you can place copies on other servers as
needed.
Importing the SSL certificate to a Telephony Application Server

Import an SSL certificate to a Telephony Application Server in an IBM Lotus
About this task
The following directory abbreviations are used in this topic:

Table 6. Directory variables used in this task
Variable Description
${TAS_ROOT} The main Telephony Application Server software directory.
Example: /enterprise
Procedure
1. Store a copy of the certificate file in the following location:
${TAS_ROOT}/ibm/certs.
2. Execute the following commands:
chown sym:sym .cer
chmod 644 .cer
3. Edit the ${TAS_ROOT}/ibm/sutbcomadapter.properties file as follows:
a. Add the following “SIPProxyCert” entry:
SIPProxyCert=${TAS_ROOT}/ibm/certs/mycert.cer
Note: If you are upgrading, the statement should already be there;

otherwise add it now.
b. Add the following “SIPProxy” entry
SIPProxy=SIP_PR_IP_address:5061;transport=TLS
Note: If you are upgrading, the statement should already be there;

otherwise add it now.
Importing the SSL certificate to a Telephony Control Server

Import an SSL certificate into a Telephony Control Server in an IBM Lotus
Procedure
1. Store a copy of the certificate file in the following location:
/usr/local/ssl/certs.
2. Rename the file to use the extension .pem; the file name is now
/usr/local/ssl/certs/mycert.pem
3. Create a symlink to the .pem file and add the contents of the file to root.pem
as follows:
cd /usr/local/ssl/certs ln -s mycert.pem "`openssl x509 -noout -hash -in mycert.pem`.0" cat mycert.pem >> root.pem
4. Log in the CMP.
5. Open the endpoint you created for WebSphere Application Server.
6. Create a new endpoint for the same WebSphere Application Server, with
following details:
a. On the SIP tab, change the transport to MTLS and change port to 5061.
b. On the Attributes tab, click the Use Server Virtual Address option.
7. Open the “Destination” you have created for routing to the old WebSphere
Application Server endpoint, and make the following changes:
a. On the Routes tab of the Destination, delete the old route.
b. Add a new route pointing to the new WebSphere endpoint.
8. Repeat steps 1 through 9 for each Telephony Control Server in the
deployment.
9. Active TCS only: Run the following command to determine the server's IP
address and port:
grep "sipsm3_vip:" /opt/unisphere/srx3000/ifw/tmp/reloc/etc/hiq8000/node.cfg
Notice that this is not your regular SIP signaling IP address.
10. Write down the IP address and port number for use in the next task.
Verifying the SIP Proxy/Registrar server's proxy.xml file

In IBM Lotus Sametime Unified Telephony deployment where you are enabling
TLS encryption, verify that the SIP Proxy/Registrar server's proxy.xml file contains
the correct IP address and port referencing the active Telephony Control Server.
About this task

${WEBSPHERE_PATH} The root installation location of IBM WebSphere Application Server 7.0.
Example: /opt/IBM/WebSphere
Procedure
1. Open the ${WEBSPHERE_PATH}/sutConfig/proxy.xml file.
2. Locate the forceRouting setting.
The setting looks like this:
forceRouting="sip:9.51.253.160:5061;transport=tls"
3. Verify that the setting uses the IP address and port that you obtained from the
active Telephony Control Server in the previous task.
The IP address and port appear in bold in this example:
forceRouting="sip:9.51.253.160:5061;transport=tls"
Restarting servers
After enabling TLS encryption in an IBM Lotus Sametime Unified Telephony
deployment, restart the affected servers.

About this task

Procedure
1. On the SIP Proxy/Registrar server, restart IBM WebSphere Application Server
as follows:
${WEBSPHERE_PATH}/AppServer/profiles/AppSrv01/bin/stopServer.sh server1 -username WAS_Admin_user -password WAS_Admin_password
${WEBSPHERE_PATH}/AppServer/profiles/AppSrv01/bin/startServer.sh server1
2. Stop the Telephony Application Server with the following command:
Remember, you only need to stop the Telephony Application Server that you
just upgraded, you do not need to stop all nodes.
/etc/init.d/symphoniad stop
3. Restart each Telephony Control Server with the following commands:
/unisphere/srx3000/srx/startup/srxctrl 3 4
If your deployment includes more than one Telephony Control Server,
remember to restart each node.
4. Start the stopped Telephony Application Server with the following command:
/etc/init.d/symphoniad start
Verifying that TLS encryption is enabled

Check the SIP registration page to verify that TLS encryption has been enabled in
your IBM Lotus Sametime Unified Telephony deployment.
Procedure
1. On the SIP Proxy/Registrar server, log in to the Integrated Solutions Console as
the WebSphere administrator.
2. Click SIP Proxy and Registrar > SIP Registration
3. In the list of SIP registrations, verify the Device Address column displays:
transport=tls for each SIP registration.
Correcting a certificate with multiple OU values

Manually correct the order in which an SSL certificate's OU values are read by IBM
WebSphere Application Server.

About this task
If your certificate uses more than one OU component, they may be read in the
wrong order, which prevents TLS encryption from working properly. Correct the
problem as follows.
For more information about this issue, see the IBM document PK89438.
Procedure
1. Create a new root certificate:
a. On the SIP Proxy/Registrar server, log in to the Integrated Solutions
Console as the WebSphere administrator.
b. Click Security > SSL certificate and key management > Key stores and
Certificates.
c. In the "Keystore usages" list, click Root certificate keystore.
d. Click on the DmgrDefaultRootStore or the NodeDefaultRootStore
depending on what type of server you have installed.
e. Click Personal Certificates > Create > Self-signed Certificate.
2. Replace the old root certificate with the new one:
a. In the root certificate keystore list, select the old root certificate and then
click Replace.
b. On the Replace panel, select the new certificate's alias from "Replace with"
list.
c. Click Delete old certificate after replacement.
d. Click Delete old signers.
3. Now update each of the chained certificates in the configuration:
a. In the list of personal certificates, select a certificate to replace.
b. Click Renew.
Configuring SUT SIP proxy/registrar security

The following steps are mandatory. When you are done, restart the TAS.
Configuring SIP security

Configuring the SIP security in an IBM Lotus Sametime Unified Telephony
deployment involves the following steps:
Application security enablement:
Enable application security on the SIP Proxy/Registrar in an IBM Lotus Sametime

Procedure
1. To begin configuring the SIP security, log in to the Integrated Solutions Console
as the WebSphere administrator.
2. Click Security > Global security.
3. Select Enable application security check box.
4. Click Apply.
5. Save your changes by clicking the Save link in the Messages box at the top of
the page.
Configuring user account repository:

Configure the IBM WebSphere Application Server user account repository in an
IBM Lotus Sametime Unified Telephony deployment.
About this task
Continue configuring SIP security by configuring the user account repository.
Procedure
1. Log in to the Integrated Solutions Console as the WebSphere administrator.
3. Click the Configure button.
4. Under Related Items, click Manage repositories, and then click the Add
button.
5. Configure the LDAP server settings for the repository, and then click OK.
6. Save your changes by clicking the Save link in the "Messages" box at the top
of the page.
7. Return to Security > Global security page.
8. Click the Configure button, and then click the Add Base entry to Realm
button.
9. In the Repository list, select the newly defined LDAP repository.
10. In the Distinguished name that uniquely identifies this set of entries in the
realm field, type the distinguished name that uniquely identifies this set of
entries within the realm.
11. In the Distinguished name of a base entry in this repository field, type the
distinguished name of the base entry within the repository from which
searches start in the directory tree; then click OK.
12. Save your changes by clicking the Save link in the "Messages" box at the top
of the page.
Configuring the trusted IP list for the SIP Proxy/Registrar server

In an IBMLotusSametime Unified Telephony deployment, add the Telephony
Control Server's IP address to the list of trusted IPs on the SIP Proxy/Registrar
server.
About this task
All SIP INVITE requests that travel through the SIP Proxy are generated by the
Telephony Control Server's B2BUA host. To ensure IBM WebSphere Application
Server can approve the requests, add, the B2BUA host name to the SIP
Proxy/Registrar server's trusted IP list.

Procedure
1. Log in to the Integrated Solutions Console as the WebSphere administrator.
2. Click Servers > WebSphere application servers

3. In the list of servers, click server1.
4. Under “Container settings”, click SIP Container Settings > SIP container.
5. Click the Custom properties link.
6. Define a new custom property as follows:
a. Click New.
b. Enter the following properties:
v Name: com.ibm.ws.sip.security.trusted.iplist
v Value: Use either the IP address, or the fully qualified host name, of the
Telephony Control Server's B2BUA.
This field can contain multiple values, separated with commas.
c. Click OK.
7. Save your changes by clicking the Save link in the "Messages" box at the top of
the page.
8. Restart WebSphere Application Server so the change can take effect:
${WEBSPHERE_PATH}/AppServer/profiles/AppSrv01/bin/stopServer.sh server1 -username WAS_Admin_user -password WAS_Admin_password
${WEBSPHERE_PATH}/AppServer/profiles/AppSrv01/bin/startServer.sh server1
Configuring authorization settings

The SIP Registrar determines if the authenticated user is authorized to modify
registrations for the specified address-of-record. This configuration step involves
configuration of the SIP Registrar and the BComAdapter.
Configuring BCom Adapter:
Edit the sutbcomadapter.properties file in the way shown.
Procedure
1. Set the STIForceStrictClientAuthentication. If the telephone number is not
defined at the Sametime repository set
STIForceStrictClientAuthentication=false. If the telephone number defined at
the Sametime repository set STIForceStrictClientAuthentication=true. True is
the default.
2. Set the STIClientAuthorizationInGNF. It is required only if the above
parameter is set to true. If the Telephony number is stored at the repository
with + in front, then set STIClientAuthorizationInGNF=true (send number
with +), otherwise set to false (send number without +).
Configuring SIP Registrar:
Configure the SIP Registrar before you configure the BComAdapter.
Procedure
1. Open the WAS_install_root/AppServer/sutConfig/authorization.properties
file for editing.
2. In the file, locate the telephonyPrefix=value setting.
3. Enter the correct telephonyPrefix value.
You can determine the correct value as follows:
a. Look up the GNFPrefixReplacement value in the BComAdapter.
b. Look up the SoftphonePrefix, which takes the format +value.
c. The telephonyPrefix is the SoftphonePrefix with the GNFPrefixReplacement
instead of a +.

For example, if:
GNFPrefixReplacement = 9
SoftphonePrefix = +5
then:
telephonyPrefix = 95
4. Now locate the authorizationType=value setting.
5. Enter the authorizationType value.
v If the telephone number is not defined at the Sametime repository set, then
set the value to basic.
v If the telephone number is defined in the repository but may not be identical
to the corresponding number provisioned at the Telephony Application
Server, then set the value to basic.
v Otherwise, set the value to aorusername (the default setting).
Set the authentication attribute at the WebSphere Application Server:
If the telephone numbers defined in the LDAP repository are identical to the
telephone numbers provisioned for each user at the Telephony Application Server,
define a login property for authenticating users in an IBM Lotus Sametime Unified
Before you begin
This step is required only if the telephone number defined in the Sametime
repository is identical to the telephone number provisioned for that user at the
Procedure
1. Log in to the Integrated Solutions Console as the WebSphere administrator
3. Click the Configure button, and then click the name of the repository.
4. Edit Login properties to include both the telephone number and the user
identification.
The telephone number attribute must appear before the user identification. For
example, if the user identification attribute is "uid", type the attribute as:
telephoneNumber;uid.
5. Click OK.
6. Save your changes by clicking the Save link in the "Messages" box at the top of
the page.
7. Restart the WebSphere Application Server so the change can take effect.
Configuring TLS trunks

Configuring security on the Telephony Control Server includes configuring
Transport Layer Security (TLS) so that there are trust certificates on both sides of
the PBX trunk.
About this task
You can create a certificate for the PBX through a trusted certificate authority.

Procedure
1. Create a certificate for the PBX using a third-party trusted certificate authority.
Or, obtain a self-signed certificate from the PBX and install it on the Telephony
Control Server as follows:
a. Copy the .cer file to each of the Telephony Control Server nodes to the
/usr/local/ssl/certs directory. Rename the file and add the .pem
extension.
b. On each TCS node, create a symlink to the .pem file. Add the contents of the
file to root.pem as follows:
# cd /usr/local/ssl/certs
# ln -s mycertfile.pem "`openssl x509 -noout -hash -in mycertfile.pem`.0"
# cat mycertfile.pem >> root.pem
2. Start the CMP and open the endpoint you have created for the PBX. Create a
protocol type to the PBX endpoint with following differences:
a. On the SIP tab, change the transport to MTLS.
b. Change port to 5061.
c. On the Attributes tab, click the Use Server Virtual Address option.
3. Create a certificate for the Telephony Control Server through a trusted
certificate authority. Or, obtain the self-signed certificate from the Telephony
Control Server and configure it on the PBX. (See your PBX documentation.)
Configuring advanced features

Depending on your telephony configuration, you can add other features to your
system
Localizing announcements
SUT is designed to be deployed to serve several languages and cultural areas at
once. Follow these steps to test whether users hear familiar announcements.
Before you begin
The system must be configured so that basic calls and conference calls work
correctly and as expected. It is done during provisioning. These languages are set
up in the section Configuring the Media Server Languages.
About this task
This topic shows you how to localize a user and a subscriber for testing purposes.
There are a number of areas that can be localized.
v Localizing the user
v Localizing the subscriber
v Localizing the conference bridge
This example shows how to support two languages, English and Spanish. In
general, you must:
1. Configure the Media Server to support both the languages we require.
2. Configure the Conference bridge on the MS to also support both languages
(and optionally operate on local numbers for each country)
3. Configure the users to a specific language.
4. Configure the subscriber belonging to the user to the same language.

Procedure
1. Click Languages.
2. In the Languages window, the default language is set to English. Unless the
dial plan is configured to use another language, English is used. Change the
Language Mode attribute from Single to Multiple before provisioning users on
to the system.
3. To add the new languages that are not in the list, click the Add button. Click
the check boxes of the languages which you want to be available for the users
who are provisioned on the system. Click Save.

4. On the TAS, the user must be localized. On the TCS, the subscriber must be
localized. The localization is done as part of the provisioning. Information
relating to the locale of the user can be retrieved from LDAP. Or, the locale
could be derived from the country code of the users SUT number. To change
the Subscriber, go to TCS > Business Groups. Select the correct Business
Group and Numbering Plan. Then select Members > Subscribers. Select the
subscriber, then select the appropriate language from the dropdown menu and
click Save.

5. Go to User & Resources > Users > User Administration > Users. Select the
same user which was altered in the previous step and change the language.

Configuring languages on the Media Server conference bridge
This topic describes how to configure announcements so they are in the local
language.
About this task
When an SUT user starts or joins a conference, announcements must in the local
language. However, the Conferencing Bridge is a number which can be dialed
publicly. There are two aspects to configuring the languages on the Media Server
conference bridge:
v setting the default language to be played when no language data is available.
v adding any additional languages which must be supported.
Procedure
1. Go to the Media Servers Node administration panel. Click the Conference
Bridge number.

2. Select the Language Property, edit the value, and enter the appropriate
default language. Valid values are shown in the table.
Language Value
German de_de
English (Great Britain) en_gb
English (United States) en_us
Spanish es_es
French fr_fr
Italian it_it
Japanese ja_ja
Korean ko_ko
Portuguese (Brazilian) pt_br
Simplified Chinese zh_cn
3. Then, ensure that the language code is the first in the list of language codes to
appear in the Conference Service properties page.

4. Check that the language being added is present in this list on the Conference
Service properties page.

5. Return to the Node administration; Terminals page and add a new entry. The
terminals are objects representing each of the supported languages on the
Media Servers Conference Bridge. There must be one Terminal for each
language that is supported on SUT. Click Add.
6. The Terminal ID always begins with conferencing and ends with the start of
the language code. Click the ellipsis button, to see a list of the prepared
languages on the system. Entering application:/Terminal_ID is sufficient; for
example: application:/Conferencing#welcome_es. Substitute es with the start
of the language code being added.
Note: The Terminal ID has a ‘-' character before the language code, but the
Application has a ‘_' character.

7. Go to the Address Binding page and add the new Terminal. When adding a
new Address Binding for additional language support, it takes the same form
as the default ones: #welcome_cn #welcome_de. Click Add.
8. In the Terminal ID field, select the Application entry created in the Terminal
tab in the previous step from the drop down menu. In the Expression field,
follow the convention of the previously created localized expressions, for
example, 997 and 998. Leave the rest of the fields in this section of the page
unchanged.

9. In the Generic Properties field, add the language property. Set the Key field
to Language and the Value field to the appropriate language code. Click Save.
10. To test the configuration, dial the conference bridge from an SUT client where
the user was set to the newly configured language.

Configuring CDR and call records
The Telephony Control Server generates call detail records (CDR) for the calls that
go through the Telephony Control Server.
About this task
The call detail records can be entered into a customer's billing solution.
Note: For calls going directly to and from the PBX device, like when the user's
unpublished PBX number is called or when the user picks up the phone to make
an outgoing call, no CDR records are created in the Telephony Control Server
because the call never went through the Telephony Control Server. If needed,
custom system integrator work can provide unified CDR records for the Telephony
Control Server and the PBXs in the network.
Setting up 911
Due to regulatory requirements, enhanced 911 (E911) calls are required to allow
emergency services to accurately define the location of the caller.
About this task
After the Sametime Unified Telephony installation, the same level of functionality
must be available to the customer for dialing emergency calls as was available
before the installation. There are several scenarios to consider.
v User dials 911 from original PBX phone - The PBX may not reconfigure the
routing rules that it currently has regarding 911/E911. The LIN numbers that are
presented to the Public Safety Answering Point (PSAP) for callback and location
identification purposes must NOT be reconfigured towards the Telephony
Control Server. Because the unified number subscribers are virtual subscribers,
the Telephony Control Server does not hold any location information about a
subscriber. As a consequence, the Telephony Control Server cannot provide LINs
or even select the optimal PSAP for the 911/E911 call.
v User dials 911 from an associated device - The provider associated with that
device would be responsible for the emergency call and the Telephony Control
Serve would not be involved in the call.
v User dials 911 from the softclient - The 911 call should be directed to the SIP
server with which the soft client (such as Sametime Connect client) is registered.
The call should not be routed through the Telephony Application Server and the
Telephony Control Server because the SIP server has knowledge about the
location information of the client.
Communications Assistance for Law Enforcement Act

If CALEA (Communications Assistance for Law Enforcement Act) support is
required, CALEA is configured on the Telephony Control Server and any incoming
calls to the unified number is available for Lawful Intercept.
About this task

Any outgoing calls made using the unified number are available using the unified
number. The calls originating from the original PBX device are not captured. Only
the unified number would be available for monitoring and not any associated
other devices of the user. The Telephony Control Server provides CALEA support
for two party calls at three levels:
v Level 1: Offline CDRs are made available to LEA upon request.
v Level 2: Call Correlation records are sent to LEA in real time.
v Level 3: The content of communication is provided to LEA by conferencing in a
LEA recording device.
Note: CALEA support for conference calls is not supported in this release.
CALEA Interfaces for the ANSI market - In the ANSI market, the monitoring
process is initiated by a warrant. CALEA is then configured for the party that is to
be monitored. The wiretaps are configured on a suspect through the Unified
Number Assistant. There is a special CALEA administrator role that is made
available to the LEA, so they can view the LEA screens on the Unified Number
Assistant and configure wiretaps. When the subscriber calls or receives a call, the
LEA is notified by a CII message containing the A and B parties being sent across
the Call Data Channel to the LEA. At the same time, the media server is signaled
to conference the A and B party together with the LEA through the PSTN gateway.
A device at the LEA automatically accepts the call and begins recording the Call
Content
CALEA support for the ETSI market - In the ETSI market, the process is initiated
by an electronically transmitted warrant that is sent to the Lawful Interception
Operation System (LIOS). A wire tap is then configured on the specified subscriber
on the Telephony Control Server. When the subscriber calls or receives a call, the
LEA is notified by a call record of the A and B parties being sent to the LEA. At
the same time, the media server is signaled to conference the A and B party
together with the LEA through the PSTN gateway. A device at the LEA
automatically accepts the call and begins recording. As the speech path is set up to
the LEA, call correlation data is also signaled through the SIP interface to the SIP
gateway to correlate the call to the call record that was passed in parallel. The
PSTN gateway has to unpack this call correlation data from the SIP message and
transmits it in the corresponding TDM call setup fields. The LEA can then correlate

the call record to the media stream they are receiving.
Setting up speed dial lists

The IBM Service checks whether speed dial lists have been configured at the PBX
phones. It also checks whether they need to be reconfigured for the unified
number subscribers on the Telephony Control Server.
About this task
IBM Service must provide this functionality.
Setting up voice mail

A typical PBX system provides the several access options for voice mail.
About this task
A typical PBX system provides the following access options for voice mail:
v Direct access - You can dial your own mailbox. Dial the service access number
for direct access and log on to the server by entering your telephone number (or
name) and password. You now have access to all messages stored in your
mailbox and to your mailbox settings. You can record messages for other users
and then send these messages.
v Guest access - You can dial an external mailbox. Dial the service access number
for guest access and dial the extension number of the required user. You can
leave a message in the user's mailbox or be transferred to a referral extension.
But, it depends on how the user has set the answering options
v Universal access - You can dial an external mailbox and access your own
mailbox. This is the same as guest access with the additional option of being
able to access your own mailbox.
v Forward access - You can redirect callers who dial your extension to your
mailbox Calls received at your extension are then forwarded to your mailbox.
Callers can leave a message for you in your mailbox and use the mailbox as an
answering machine.
v Transfer access - You can transfer callers to your mailbox. If you want to give
the caller the option of leaving a message for someone else or if the caller is
unable to enter a user's extension number or if this extension number is to
remain hidden from the caller, you can connect the caller directly to the mailbox
by dialing the transfer access number. This option is of particular interest if you
are responsible for switching calls. This feature is typically used by an
operator/attendant.
v Callback access - You can access your mailbox using the mailbox key on the
telephone if your mailbox contains new messages. This access mode skips asking
the user to enter the number/name and instead just prompts for the password.
v Out call access - A call from your mailbox automatically informs you when new
messages appear in your mailbox.
An administrator can configure multiple voice mail systems:

v The customer could have multiple (heterogeneous) voice mail systems, including
legacy systems that need to be supported
v It can be configured to provide different access numbers for different nodes on
the same system.

v It can support multi-lingual environments, which might then require different
access numbers for each language.
You configure multiple voice mail systems through the Common Management
Portal. These numbers can be assigned to users such that when the user's rules or
preferences forward an incoming call to voice mail, the specified voice mail system
is reached. When configuring a voice mail system through the CMP, the
administrator should provide a Forward Access number.
The administrator can then configure a voice mail target (only one) for each user
by assigning one of the configured voice mail systems to the user through the
CMP.

Notices
This information was developed for products and services offered in the U.S.A.
IBM may not offer the products, services, or features discussed in this document in
other countries. Consult your local IBM representative for information on the
products and services currently available in your area. Any reference to an IBM
product, program, or service is not intended to state or imply that only that IBM
product, program, or service may be used. Any functionally equivalent product,
program, or service that does not infringe any IBM intellectual property right may
be used instead. However, it is the user's responsibility to evaluate and verify the
operation of any non-IBM product, program, or service.
IBM may have patents or pending patent applications covering subject matter
described in this document. The furnishing of this document does not grant you
any license to these patents. You can send license inquiries, in writing, to:
IBM Director of Licensing

IBM Corporation
North Castle Drive
Armonk, NY 10504-1785
U.S.A.
For license inquiries regarding double-byte (DBCS) information, contact the IBM
Intellectual Property Department in your country or send inquiries, in writing, to:
Intellectual Property Licensing

Legal and Intellectual Property Law
IBM Japan Ltd.
1623-14, Shimotsuruma, Yamato-shi
Kanagawa 242-8502 Japan
The following paragraph does not apply to the United Kingdom or any other
country where such provisions are inconsistent with local law:
INTERNATIONAL BUSINESS MACHINES CORPORATION PROVIDES THIS
PUBLICATION “AS IS” WITHOUT WARRANTY OF ANY KIND, EITHER
EXPRESS OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
WARRANTIES OF NON-INFRINGEMENT, MERCHANTABILITY OR FITNESS
FOR A PARTICULAR PURPOSE. Some states do not allow disclaimer of express or
implied warranties in certain transactions, therefore, this statement may not apply
to you.
This information could include technical inaccuracies or typographical errors.

Changes are periodically made to the information herein; these changes will be
incorporated in new editions of the publication. IBM may make improvements
and/or changes in the product(s) and/or the program(s) described in this
publication at any time without notice.
Any references in this information to non-IBM Web sites are provided for
convenience only and do not in any manner serve as an endorsement of those Web
sites. The materials at those Web sites are not part of the materials for this IBM
product and use of those Web sites is at your own risk.

IBM may use or distribute any of the information you supply in any way it
believes appropriate without incurring any obligation to you.
Licensees of this program who wish to have information about it for the purpose
of enabling: (i) the exchange of information between independently created
programs and other programs (including this one) and (ii) the mutual use of the
information which has been exchanged, should contact:
IBM Corporation
5 Technology Park Drive
Westford Technology Park
Westford, MA 01886.
Such information may be available, subject to appropriate terms and conditions,

including in some cases, payment of a fee.
The licensed program described in this information and all licensed material
available for it are provided by IBM under terms of the IBM Customer Agreement,
IBM International Program License Agreement, or any equivalent agreement
between us.
Any performance data contained herein was determined in a controlled

environment. Therefore, the results obtained in other operating environments may
vary significantly. Some measurements may have been made on development-level
systems and there is no guarantee that these measurements will be the same on
generally available systems. Furthermore, some measurements may have been
estimated through extrapolation. Actual results may vary. Users of this document
should verify the applicable data for their specific environment.
Information concerning non-IBM products was obtained from the suppliers of

those products, their published announcements or other publicly available sources.
IBM has not tested those products and cannot confirm the accuracy of
performance, compatibility or any other claims related to non-IBM products.
Questions on the capabilities of non-IBM products should be addressed to the
suppliers of those products.
All statements regarding IBM's future direction or intent are subject to change or
withdrawal without notice, and represent goals and objectives only.
All IBM prices shown are IBM's suggested retail prices, are current and are subject
to change without notice. Dealer prices may vary.
This information is for planning purposes only. The information herein is subject to
change before the products described become available.
This information contains examples of data and reports used in daily business
operations. To illustrate them as completely as possible, the examples include the
names of individuals, companies, brands, and products. All of these names are
fictitious and any similarity to the names and addresses used by an actual business
enterprise is entirely coincidental.
COPYRIGHT LICENSE:
This information contains sample application programs in source language, which

illustrate programming techniques on various operating platforms. You may copy,
modify, and distribute these sample programs in any form without payment to

IBM, for the purposes of developing, using, marketing or distributing application
programs conforming to the application programming interface for the operating
platform for which the sample programs are written. These examples have not
been thoroughly tested under all conditions. IBM, therefore, cannot guarantee or
imply reliability, serviceability, or function of these programs. The sample
programs are provided "AS IS", without warranty of any kind. IBM shall not be
liable for any damages arising out of your use of the sample programs.
Each copy or any portion of these sample programs or any derivative work, must
include a copyright notice as follows:
© (your company name) (year). Portions of this code are derived from IBM Corp.
Sample Programs. © Copyright IBM Corp. _enter the year or years_. All rights
reserved.
If you are viewing this information softcopy, the photographs and color
illustrations may not appear.
Trademarks
These terms are trademarks of International Business Machines Corporation in the
United States, other countries, or both:
IBM
AIX
DB2
DB2 Universal Database Domino
Domino
Domino Designer
Domino Directory
i5/OS
Lotus
Lotus Notes
Notes
OS/400
Sametime
WebSphere
AOL is a registered trademark of AOL LLC in the United States, other countries, or
both.
AOL Instant Messenger is a trademark of AOL LLC in the United States, other
countries, or both.
Google Talk is a trademark of Google, Inc, in the United States, other countries, or
both.
Yahoo! is a registered trademark of Yahoo, Inc. in the United States, other

countries, or both.
Yahoo! Messenger is a trademark of Yahoo, Inc. in the United States, other

countries, or both.
Java and all Java-based trademarks and logos are trademarks or registered
trademarks of Oracle and/or its affiliates.
Notices 267
Microsoft, and Windows are registered trademarks of Microsoft Corporation in the
United States, other countries, or both.
Intel and Pentium are trademarks or registered trademarks of Intel Corporation or

its subsidiaries in the United States, other countries, or both.
Linux is a trademark of Linus Torvalds in the United States, other countries, or

both.
Other company, product, or service names may be trademarks or service marks of

others.

Printed in USA

Lotus Sametime Unified Telephony: Installation Guide

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Lotus Sametime Unified Telephony: Installation Guide

Uploaded by

Copyright:

Available Formats

Lotus Sametime

Lotus Sametime Unified Telephony

© Copyright IBM Corp. 2009, 2011 iii

Sametime Unified Telephony PDF library

IBM Lotus SametimeUnified Telephony software offers the immediacy of instant

© Copyright IBM Corp. 2009, 2011 1

2 Lotus Sametime Unified Telephony: Installation Guide

Chapter 1. Sametime Unified Telephony overview 3

Supported interfaces, protocols, PBXs, and gateways

4 Lotus Sametime Unified Telephony: Installation Guide

Chapter 1. Sametime Unified Telephony overview 5

Lotus Sametime Standard Server

IBM Lotus Sametime Standard server lets a community of users to collaborate in

Lotus Sametime Connect Client

External Telephony Equipment

Telephony Application Server

Telephony Application Server

There can be up to eight Telephony Application Servers on each SUT installation.

Each Telephony Application Server monitors up to 15,000 users. User affinity is

6 Lotus Sametime Unified Telephony: Installation Guide

Telephony Application Server performs the following functions:

Chapter 1. Sametime Unified Telephony overview 7

The Media Server hosts and executes the following services:

Media Server Scalability

Each Telephony Application Server is provided with a single-accompanying Media

When scaling up to multiple Telephony Application Servers with their

8 Lotus Sametime Unified Telephony: Installation Guide

A Telephony Application Server can be connected to one Sametime server or a

Media Server Conferences:

Media Server: Offboard

A Sametime Unified Telephony cluster supports up to eight external or offboard

Chapter 1. Sametime Unified Telephony overview 9

Telephony Control Server

The Telephony Control Server uses the CSTA (Computer Supported

The Telephony Control Server has the following functional components:

10 Lotus Sametime Unified Telephony: Installation Guide

The supported deployment scenarios are as follows:

Minimal server deployment

The Sametime clients are connected to a Domino Sametime server, a Telephony

The Telephony Application Server is connected to the Telephony Control Server

Chapter 1. Sametime Unified Telephony overview 11

Multiple TAS server deployment with Standby TAS

12 Lotus Sametime Unified Telephony: Installation Guide

Deployment with IP PBX environment

Deployment with non-IP PBX environment

Chapter 1. Sametime Unified Telephony overview 13

Setting up hardware for a Telephony Control Server

Telephony Control Server

TCS hardware installation checklist

The Telephony Control Server hardware checklist:

Telephony Control Server cabling

You will need the following items:

© Copyright IBM Corp. 2009, 2011 15

The dimensions of the server are as follows:

Configuring BIOS Settings

3. On the System Configuration and Boot Management screen, selectDate and

16 Lotus Sametime Unified Telephony: Installation Guide

5. Back on the System Configuration and Boot Management screen, select

18 Lotus Sametime Unified Telephony: Installation Guide

9. On the Boot Manager screen:

a. Select Change Boot Order.

Configuring the RAID unit setup

Before you begin